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
Your state machine would be instantiated for the user and stored in the user's session. As the user invoked web API methods, you'd call Fire methods on the state machine. The state machine would in effect maintain the state of the user's session. You could include multiple state machines, build hierarchies, or approximately orthogonal relationships, all housed in the session object. The state could be persisted to storage to survive server restart or the user's session expiring and being purged from memory.
To use the state machine in web scenarios where the context usually only lives for the duration of each request, I recommend using the External State Storage strategy.
While constructing the state machine, pass in lambdas that will update and retrieve some external state. This may involve updating a key in the user cookie or session, or updating a database field for the user. Every time a request comes in, the state machine can be re-constructed with the same lambdas. As long as all the state is persisted somewhere that will survive outside of the request, it doesn't matter if the actual state machine object is re-constructed for each request.
Could anyone give an example of how this tool could be used in a web api world in a more interactive where user input causing transitions
The text was updated successfully, but these errors were encountered: