Totally Async refactoring idea

[panManfredini]

Motivation

It suck a bit that async is not fully supported, meaning async-await pattern is not supported inside a transition (one can use a promise with callback to a transition, no problem), since the state must be changed sincronusly to guarantee a consistent state change and no possible race conditions. Also it sucks that it throws for transition in transition or similar, a good tool helps the developer and it feels like he shouldn't be worring about these things, should just work.

Refactoring idea:

Make the whole transition async, use the lock mechanism already in place. State transition would hold a promise that resolve when all watchers are called. This transition-promise gets stored in a global object. Each new transition check this object, exchange the found promise with one that resolves on its own transition and before start changing the state will await the promise previously found in the object.

Pros:

• Now Naturally all transition wait for each other and get executed in order.
• Nested transition also wait for completion and get executed in order
• Can use async-await in transition
• Fucking elegant solution

Preliminary syntax:

stateVar.AddTransition("data-fetch", async ()=>{
         await lock(()=>{ change state here; });
         await Net.fetch(....)  // do network call, the state is not locked here and other transition can happen in the mean time
         await lock(()=>{ change state here; }); // regain lock while before waiting on eventual transitions.
});

Cons:

• Is it really useful? I mean one can easily do the same pattern by just two independent transition and a net call.
• I don't seem to easily find a less ugly syntax.
• I get that Redux supports nested transitions and now one could do it also with impera, but why would you ever want to do that? Why would anyone want to run a transition from a callback that is supposed to apply UI state change, if you need to change state again, do it in the first transition, no?