-
Notifications
You must be signed in to change notification settings - Fork 712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decorators, begone! #2947
Decorators, begone! #2947
Conversation
Decoration is in fact quite a simple process that is applied on entry to rendering: we take a base renderer, transform it with a decorator, and then render a report with it. The new render.Decorate() function does exactly that. There is one exception. When rendering an individual node, e.g. for showing its details panel in the UI, we must not lose the node during decoration. That requires some special logic, which previously resided in the PreciousNodeRenderer, and now lives in handleNode.
I've tested the correctness of this by running
against master and this branch and diffing the resulting reports. |
and rename existing IsConnected const to IsConnectedMark
9c8422a
to
5095116
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice.
I think I would have broken the steps down a little more, e.g. the refactoring to extract isNotBar
in render/filters_test.go
can stand alone.
app/api_topologies.go
Outdated
} | ||
topologies = append(topologies, desc) | ||
}) | ||
return updateFilters(rpt, topologies) | ||
} | ||
|
||
func decorateWithStats(rpt report.Report, renderer render.Renderer, decorator render.Decorator) topologyStats { | ||
func decorateWithStats(rpt report.Report, renderer render.Renderer, filter render.FilterFunc) topologyStats { |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
Decorators were just a complicated way of constructing filters.
so it becomes accessible w/o having to construct a Filter renderer.
instead of constructing temporary Filter renderers. This also makes clearer what is going on.
to de-decorate
b42d456
to
a12d707
Compare
Decorators turn out to be an unnecessary abstraction that rather obscures what's going on. So let's get rid of them!
Decorators were used to dynamically construct filters from UI selections - e.g. namespaces, system vs app containers, etc; the selectors in the bottom left corner of the current scope UI - and apply them to the output of topology renderers - pods, containers-by-image, etc; the selectors at the top centre of the current scope UI. Decorators were accomplishing that in a rather complicated way, by composing renderers that wrap the base topology renderers.
This PR unravels all that.
The filter selection from the UI is now turned into a
FilterFunc
, which weApply()
to the output of topology renderers. Therender.Render()
function does exactly that, and very clearly so. The one place where we need to do something special is when rendering a single node, e.g. for the details panel in the UI. See comments in thehandleNode
code.The PR looks larger than it actually is. There are a bunch of mechanical changes that touch several files, especially the removal of Decorators from the
Renderer.Render()
signature, and use of the newrender.Render()
function. The individual commits are self-contained, but the first one is very much an intermediate step which is largely superseded by later commits. Also note that GH does a poor job of showing the diff for the change that moves the filter logic toFilterFunc.Apply()
.