-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow canceling state transitions #745
Comments
I think this feature makes sense. If you keep user authentication status in the state machine it would be great to be able to bounce an unauthenticated user out of the "logged in" state tree. Example: question on stackoverflow and code on jsFiddle. This raises the question: where do you do after canceling a state transition? Perhaps along with the cancel event you have to provide a destination state. |
Nope, this is definitely not allowed under the state chart model. The entire point of states is to avoid situations like this. @viatropos, you should be modeling your async operations as events being sent to the state manager. It is the responsibility of the current state to handle them. This forces you to be more rigorous about modeling the different states you can be in, which is why they are beneficial. If you'd like to discuss your particular use case more, we can figure out a way to model it in terms of states and events without having to cancel transitions, I'm sure. :D |
So, in my situation above (authenticated actions with the state manager), all the logged-in actions should go in the authenticated. That makes sense. What is a good strategy for making sure controls (like links) disappear once the user logs out? |
@brundage The way I like to model this is to have the state that is responsible for handling those actions also be responsible for showing and removing related views. This is basically the problem that the outlet pattern is designed to handle: http://emberjs.com/guides/outlets/. |
Thanks @tomdale. |
@tomdale, what's wrong with canceling state transitions? AFAIK, David Harel's paper does not explicitly forbid this case. |
@ftokarev The advantage of state charts is that they help eliminate ambiguity about behavior. Canceling a transition creates ambiguity because it is unclear what the current state should now be. If a state wants to cancel a transition, it should just explicitly transition into a new state; that way it is clear from reading the code exactly what the new state is. |
I think the state which cancelled a transition should become the current state |
@ftokarev Do you have a reference to the concept of cancelation in the literature? |
@tomdale No |
Related to the previous issue, it would be very useful to prevent state transitions. Perhaps another flag on the
transition
object:What do you think?
A use case is, if you have async operations, and somewhere totally unrelated, the code calls
goToState
, it should prevent the transition until the async operation is complete.The text was updated successfully, but these errors were encountered: