Wrap action functions in setTimeout?

[dashed]

It's a common use case that action functors are normally tied to virtual DOM event callbacks within components in react.js. EventEmitters (node.js or 3rd-party) are not async in nature, unless otherwise designed to be.

Thus, whenever an emit function is called, it's done synchronously which begin from the action to the store (and chained stores).

Action functors should be executed in fire-and-forget fashion. Thus, I think we should wrap action functions in setTimeout with 0ms delay.

@spoike thoughts?

[bripkens]

strong +1 for this

[spoike]

I was under the impression they were deferred already.

I'm all 👍 for this

[dashed]

Created PR at #23. Should we bother worrying about using requestAnimationFrame whenever it's available?

[spoike]

I'm pretty sure requestAnimationFrame is tied to the browser's frame rate while setTimeout(..., 0) isn't. We really want to run the actions as quickly as possible though.

Should we provide an option for using requestAnimationFrame instead if available? This could help out projects (HTML5 games perhaps) that rely on this.

[bripkens]

Wouldn't you normally try to run your logic as fast as possible and then batch your UI updates to 60fps? If so, setTimeout(...) should suffice.

Then again, we can always add requestAnimationFrame support once somebody has a need for it.

[dashed]

Here is a nice polyfill for nextTick: https://github.com/medikoo/next-tick/blob/master/index.js

1. MutationObserver is faster than setTimeout, and probably as fast as you can get in modern browsers that support it: http://caniuse.com/mutationobserver
2. setImmediate would be used for IE10+.
3. Finally, setTimeout as final fallback. (<= IE9)

[dashed]

bluebird promise library does something similar: https://github.com/petkaantonov/bluebird/blob/master/src/schedule.js

[dashed]

I amended my PR to use the next-tick module, and as well as switch it out via utils.nextTick.