More answers to questions from Mike Skirpan

Antranig Basman antranig.basman at
Wed Jun 29 16:01:35 UTC 2016

This week's Infusion-related questions from Mike Skirpan at

 > When you register a listener, does the function it calls by
 > default pass the component that is listening for the event? I'm
 > noticing that often in examples functions take in things like:
 > myListenerTrigger = function (that) {} without the listener
 > explicitly passing an argument. However, you can also write
 > listeners that have explicit functions with declared arguments.
 > I'm guessing you only do that when you're writing a
 > "library-like" component where you don't know which component will
 > use listeners from that grade. Is that right?

What's going on here is that the built-in lifecycle events onCreate, 
onDestroy and afterDestroy all have a standard signature which just 
consists of ({that}).
Any listener which makes no entry in "args" simply receives the original 
firing signature - this is true in all situations. Many events fired 
from a component will indeed fire the component reference in the first 
argument position (in addition to others) but this is a general 
convention rather than a hard and fast rule. Any listener which 
explicitly wants a different signature can request it in "args" 
(including requesting original arguments via {arguments}) but this 
always completely replaces the original signature.

 > How does fluid.each() work normally? I thought it was similar to
 > jQuery.each() however, how does this work given that I don't see
 > other components in chart authoring with a bindings block that has
 > explicit modelPath and selector options. I think I don't understand
 > bindings blocks because .each() should be fairly standard.

We looked over this issue in our chat and verified that there's nothing 
special about the operation of fluid.each -
and verified that the convention in the "bindings" block in the various 
binders is indeed for the key to represent a selector name and the value 
to represent a model path - e.g. 
- see

 > Is it recommended to have selectors and declared components use the
 > same key names? Often you're selectors correspond to containers of
 > components, but I'm not sure if this is bad for namespacing?

Yes, it is perfectly reasonable and indeed desirable for components to 
have a member name which corresponds to a selector name.

 > In which scopes should sub-components be declared? I take it there is 
 > a difference between writing a parent declaration meant to wrap up a 
 > few components vs. defining a fresh grade for a component. In my
 > case, I'm wondering if my graph canvas (ie, Representation Component) 
 > which needs several sub-components should have those sub-components
 > declared in the file that creates the grade or only in the parent
 > declaration. For an example look at src/js/dataDashboard.js vs.
 > 'src/js/graphCanvas'. The graphCanvas component will have sub
 > components, but I'm unsure whether I should be declaring that
 > relationship in dataDashboard or not?

This is a pretty interesting issue. A few years past, our standard 
recommendation was for grade definitions to be self-contained - that is, 
to not include any IoC references which could not resolve within the 
scope of the "patch of component tree" being defined. However, more 
recently we realised that this recommendation inhibits many valuable use 
cases for reuse - which could be called cases of "interactional reuse". 
This new understanding is reflected in some wording at the head of our 
"Understanding Components" page: 
- where it reads "or relationships between other components".

So our new recommendation is to support grade definitions which include 
unbound references, where this leads to definitions which are more 
compact and readable, and where there is some conceivable use case where 
instances of the grade could bind within a variety of contexts.

 > Given that I'm ready to go ahead and kick off milestone 1 since I'm
 > actually starting to do far more than that milestone, I'm wondering
 > if I can expect components to actually render even if I haven't used 
 > all the selectors I've defined yet?

Yes, superfluous configuration in components is always harmless. Well, 
perhaps we could say "mostly harmless" : P

 > For my Representation Component, if I need both a graph type
 > selection and some parsed data in order to generate it, what is the
 > best event system to verify this? Should I have two events that each 
 > check if the other has fired yet? Or is there a better way to handle 
 > this logical flow?

In our call, we discussed that issues of this kind are always improved 
by being pushed into the model layer of the application. This allows one 
to express logical constraints between instants of time, instead, as 
mappings between values. Then you can rely on Infusion's model relay 
system to "lift" the constraint into the equivalent relationship between 
"signals" (in the FRP sense) by observing the output model state using a 
modelListener. In this case you would write a modelRelay definition that 
checks whether both of two input values are defined (perhaps using the 
"&&" binop rule) and then outputs "true" if they are.

 > We discussed an issue the other week about field selections for
 > graphing. The problem was how to decide whether a user wants to graph 
 > all the rows for a particular column or whether they want to pluck
 > certain values from within a column.

In our call we talked over some UX design workflows, wireframing, etc. 
and how these might work on a project that had dedicated design staff. 
We decided to explore this issue in more detail with some wireframes and 
interaction diagrams over the next week or two.



More information about the fluid-work mailing list