You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked through the issues, and you have spoken to the desire to keep the machine 'synchronous'. Which makes a lot of sense.
However, I have some actions that go off and do some web requests, which return a Promise. The ideal way of managing this is to use Await, as it keeps the machine synchronous to itself. However, my understanding is that I need to make all the calling functions from state.evaluate() to the action set with '.entry' or '.effect' 'async', and in several places in between explicitly call 'await xxxx()'.
Am I missing something? Or do I need to fork your library and add a state.evaluateAsync() et al methods?
The text was updated successfully, but these errors were encountered:
My initial inclination would be to have a subsection of your state machine represent the web request - a state called pendingResponse or similar, that on entry initiates the call, then in your .then callback, fires an event back into the machine causing it to transition out of pendingResponse.
Thanks for the input. I initially tried the approach you describe. There is a point in your code where you iterate through the all the actions on a transition. I believe the semantics are such that each action should complete before the next one is 'fired' (ie the exit action from the from state before the transition action before the entry of the to state etc.). I could of redesigned the machine however it was getting really complex and I found by allowing an action to return a promise and then machine awaiting for it to be fulfilled really simplified the machine in this instance. It also allowed for the 'evaluate' call to return a promise that could be awaited, that greatly simplified the calling code.
I ended up forking and created a version that provides async/await semantics but I wonder if it would be possible to do some sort of clever stuff with generics to allow for either option to be chosen.
Hi David,
I looked through the issues, and you have spoken to the desire to keep the machine 'synchronous'. Which makes a lot of sense.
However, I have some actions that go off and do some web requests, which return a Promise. The ideal way of managing this is to use Await, as it keeps the machine synchronous to itself. However, my understanding is that I need to make all the calling functions from state.evaluate() to the action set with '.entry' or '.effect' 'async', and in several places in between explicitly call 'await xxxx()'.
Am I missing something? Or do I need to fork your library and add a state.evaluateAsync() et al methods?
The text was updated successfully, but these errors were encountered: