Decide on synchronous vs asynchronous data handling
monokee opened this issue · 2 comments
The current implementation of the reactor is a brute-force approach to auto-batch incoming change requests to avoid multiple iterations of the same computations or reactions. This batching is done by scheduling the computation until the next available frame via the browsers RAF interface which makes the reactor and all data handling asynchronous.
If this behaviour is how we want to progress in the future Component.set()and ```Store.set````
both have to return a promise object.
If we decide against asynchronous data setting we have to refactor to a non-raf based, synchronous reactor.
Pros of asynchronous reactor
Many subsequent requests to change the same piece of data will only result in a single execution of the data's side effects (computations, reactions). Consider a slider that is being dragged by a user which can easily result in more data change requests than reactions which can be painted onto the screen on a frame by frame basis. By buffering reactions to such inputs to only execute once per available frame we essentially optimize the engine for the purpose of user interface drawing which is good.
This could be a good place to more deeply integrate the (currently rather pointless) Server object or more generally all asynchronous tasks such as network requests. Side effects like computations and even reactions could contain arbitrary async logic.
Cons of asynchronous reactor
Syntax in user implemented code becomes less straight forward as we move away from simple synchronous procedural logic to the asynchronous promise syntax. This could be confusing as the data changes are really synchronous in nature as far as the user can tell because there are no network requests or user implemented timeouts.
Async handling implemented in 1.04 beta. Keeping this open b/c I'm undecided if this is the way to go and probably will be until I've written more example components
Fast forward to 2022 and I eventually settled on a hybrid approach were all state read/write ops are synchronous and observer resolution is asynchronous.