In Reacl, a single call to send-message! can cause multiple state updates, which are batched when done from a DOM event, but not if done from a 'timeout', ajax callback or a send-message in a test-case.
But I argue that we always want to batch the state updates following a send-message. Otherwise, the application will see inconsistently updated states, which might also cause a 'loss of data' when e.g. 'did-update' is used a lot.
Or as seen from the implementation: when committing multiple states at the end of a Reacl cycle, and when updates are not batched, each setState can cause the start of another cycle, while not all states are committed yet. So the order would also make a difference there. This is, I think, not the case when we batch the updates.
The batching can easily be done with the unofficial React API js/ReactDOM.unstable_batchedUpdates. Maybe it could be done in a more complicated way by, threading all updates through the 'uber component', should React remove that API later.
Note that calling send-message! multiple times from a non-event context has the same "effect", but I'll leave that as a separate problem (if it is one at all).
mikesperber
commented
5 years ago
Currently, React batches state updates only when they are done from a DOM event handler. Batching means, that any rerendering or licecycle methods only run after a batch of states has been updated all together. (also see here https://stackoverflow.com/questions/48563650/does-react-keep-the-order-for-state-updates/48610973#48610973 )
In Reacl, a single call to
send-message!can cause multiple state updates, which are batched when done from a DOM event, but not if done from a 'timeout', ajax callback or a send-message in a test-case.But I argue that we always want to batch the state updates following a send-message. Otherwise, the application will see inconsistently updated states, which might also cause a 'loss of data' when e.g. 'did-update' is used a lot.
Or as seen from the implementation: when committing multiple states at the end of a Reacl cycle, and when updates are not batched, each setState can cause the start of another cycle, while not all states are committed yet. So the order would also make a difference there. This is, I think, not the case when we batch the updates.
The batching can easily be done with the unofficial React API
js/ReactDOM.unstable_batchedUpdates. Maybe it could be done in a more complicated way by, threading all updates through the 'uber component', should React remove that API later.Note that calling
send-message!multiple times from a non-event context has the same "effect", but I'll leave that as a separate problem (if it is one at all).