Shouldn't state emissions be microtask queued? about cycle-onionify HOT 6 CLOSED

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

from cycle-onionify.

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?

from cycle-onionify.

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.

from cycle-onionify.

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?

from cycle-onionify.

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.

from cycle-onionify.

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.

from cycle-onionify.