Shouldn't state emissions be microtask queued?

[ntilwalli]

On multiple occasions I've triggered a stack overflow when a state emission causes multiple reducers to be emitted on the same turn of the event loop, which can cascade. In the example I just dealt with an HTTP response (with 125 results) causes a reducer emission to store the array of results in the state, which synchronously causes a collection to be created with 125 components each of which has a few startup reducers... The stack blew up on Chrome because there was some circular state issues... The exact details I haven't tracked down, but when I delayed the initial reducers from the each collection component, the issue went away. Similarly when I hacked in a delay into onionify.js the issue goes away... like so...

sources[name] = new StateSource_1.StateSource(state$.compose(delay_1.default(1)), name);

Shouldn't state updates be async?

[staltz]

Hey @ntilwalli I think onionify currently has the race condition problems that cycle/run used to have (with regard to cross-driver startup). So either we replicate that solution in this codebase, or wait for the next version of Cycle.js where onionify could be used as a "plugin". I prefer the latter but we can also do the former (PR please?).

But batching state updates as one scheduled state update sounds good. Smart idea

[ntilwalli]

Thanks for the response. I could def PR this, after looking at the solution in run. How would the plugin architecture fix this? Or are you just saying if we waited until the next version of Cycle is released, we could avoid fixing this twice?

[staltz]

Hey Nikhil, if we get a PR, it should use a buffer like in cycle/run and this is overall a synchronous approach. So please don't send a PR to add delays because that's not a good solution (it adds noticeable disadvantages to other users and use cases).

The plugin system would help because then onionify would be like a "driver", and then it would use the solution that is currently inside cycle/run.

[ntilwalli]

Yeah, the delay/debounce approach is not appropriate. I had updated my comment to indicate that. I'll look at how it was accomplished in run. I'm surprised that you're proposing onionify as a driver in the next version of cycle. I thought drivers are specifically associated with sinks that have side-effects. I assumed onionify would be a pure adapter in that architecture. Has your thought-process changed or am I misunderstanding?

[staltz]

I thought drivers are specifically associated with sinks that have side-effects. I assumed onionify would be a pure adapter in that architecture. Has your thought-process changed or am I misunderstanding?

Yes it would not be a driver, it would be a plugin, that's why I referred to it as "driver" with quotation marks two comments above.

[ntilwalli]

Being a pure-plugin (adapter?) means there's no interaction with run, so even in the new architecture it wouldn't get the benefit of the built-in microtask queueing. Pure-plugins like onionify would need to implement the queueing for themselves similar to what I'm doing in the PR.