These are chat archives for jdubray/sam

22nd
Jan 2018
RayoGundead
@RayoGundead
Jan 22 2018 02:28
who here uses promise.all and array queue for model.present?
dunno if I might be doing something wrong
RayoGundead
@RayoGundead
Jan 22 2018 02:35
The idea is for the acceptors in present to wrap the tasks in promise then push into an array and then promise.all waits for all the tasks before calling stateFunc/render/emit.
Jean-Jacques Dubray
@jdubray
Jan 22 2018 03:21
@RayoGundead what are you trying to gain? since SAM is a reactive loop (Action->Model->State) there is no need that I can think of to manipulate the flow. Personally that's what I don't like in all these "modern" programming techniques, IMHO, control flow manipulation is an anti-pattern. SAM has a well defined step, you can't go around it, unless it is an obvious/equivalent optimization.
In the samples that I provide I mount all the invidual acceptors and run them based on the specified order.
RayoGundead
@RayoGundead
Jan 22 2018 05:24

action proposals can be queued and then dequeued via NAP.

this might work for a problem I'm currently having.
sorry for the bother.

Jean-Jacques Dubray
@jdubray
Jan 22 2018 09:18
no problem, it should be easy to know if the model is waiting on an API call to return. Logically/generally, you cannot process another proposal until it completes, though some part of the application state can be parallelized in specific scenarios. All you have to do is queue the proposal and present it again in NAP. You can even implement some behavior where only the latest proposal is processed or the entire queue (one after another). Hopefully, it's never a big queue.
IMHO, that's the power of temporal logic, you never get lost and can make simple adjustments as needed. It would be harder to reason over a large queue (>5 proposals) because actions can only apply to a specific state and now you have an action which proposal will be applied several steps after it was triggered. These cases should be avoided.