Message from JavaScript discussions

December 2016

— I think I see why it is confusing

— 

I will remove promise functions from callback dependencies, and simply use return to send the state back. I can check if the callback returns anything and decide to update or not

— That way, too, there will not be an update boolean either, more simple :)

— Great

— More functional

— I've gone off the rails... I wound up making an action execution manager

— Why? I predicted a special problem. Since each action gets a COPY of state, which it updates the store with: what happens when 2 actions on the same store get fired at the same time? The last action to update the store would overwrite the changes of the first

Message permanent page

— And I can't just let actions mutate state directly...

— So the manager adds actions to a queue and executes them asynchronously, updating a temporary state object. Once all the actions are done and the queue is empty, THEN state gets updated :3

Message permanent page

— Also! to solve the problem of different actions having different state, I made it so they don't GET the actual state, but rather the PENDING state of the current queue!

Message permanent page

— So per-cycle of executed actions, they all act on the same mutable, pending state

— Floofies you are solving a problem that you dont need to have