Side effects and ordering in flyd.on

var x = flyd.stream()
flyd.on(console.log.bind(console,'one'),x)
flyd.on(console.log.bind(console,'two'),x)
flyd.on(console.log.bind(console,'three'),x)
x('fire')

This gives the result

three fire
two fire
one fire

This seems counter intuitive to me and caused some issues for me. Is there any rationale for this behavior? Could we change it? This seems like a major design decision, and if this was intended, I cannot understand the rationale.

[garkin]

The problem is a backward compatibilty. It will change the order of execution for already existing programs. It would be a breaking change.

If we forget about that - it could be usefull for simple cases. Could be planned for a major version increment.

On the second thought, in complex and dynamic topologies it won’t help. Order there won’t be obvious from the declaration, and you should not rely on it.

[garkin]

This is a result of topological sort of the dependency graph. It’s needed for atomic updates. For example in this case sorted nodes array will look like [OnBbb, bbb, OnCc, cc, bb, b, c, d]. Array with sort results should always be iterated in reverse to the build order due the nature of such sort. This is why you could not change iteration order in the unwrapping loop.

But it is possible to reverse node children iteration order during build. (both for(of [...listeners]) loops in the updateDeps() and in the findDeps()) In this case you will get following order:

And sorted nodes: [d, OnCc, cc, c, OnBb, bbb, bb, b]. This will result in the sort being sometimes closer to the natural order of children.