Allow transitions in callbacks #88
Conversation
This adds the possibility of "starting" a state machine and have it
execute multiple state transitions in succession, given that no errors
occur.
The equivalent code without this change:
```go
var errTransition error
for errTransition == nil {
transitions := request.FSM.AvailableTransitions()
if len(transitions) == 0 {
break
}
if len(transitions) > 1 {
errTransition = errors.New("only 1 transition should be available")
}
errTransition = request.FSM.Event(transitions[0])
}
if errTransition != nil {
fmt.Println(errTransition)
}
```
Arguably, that’s bad because of several reasons:
1. The state machine is used like a puppet.
2. The state transitions that make up the "happy path" are encoded
outside the state machine.
3. The code really isn’t good.
4. There’s no way to intervene or make different decisions on which
state to transition to next (reinforces bullet point 2).
5. There’s no way to add proper error handling.
It is possible to fix a certain number of those problems but not all
of them, especially 2 and 4 but also 1.
The added test is green and uses both an enter state and an after event
callback.
No other test case was touched in any way (besides enhancing the
context one that was added in the previous commit).
This adds a context and cancelation facility to the type `AsyncError`. Async state transitions can now be canceled by calling `CancelTransition` on the AsyncError returned by `fsm.Event`. The context on that error can also be handed off as described in looplab#77 (comment).
|
I'll still want to put the two tests into examples. I'll finish this up hopefully by next week. But I wanted to give @maxekman something to look at. |
|
Thanks for the PR! Looks good on a quick review. Ping me when you feel done. |
|
Hey guys :) Any progress on this one? |
|
Hey hey, @annismckenzie any updates on this? |
Sorry about the long wait. I'm scheduling some time during work hours to finish this. |
@maxekman I pulled out the two tests into their individual examples. I feel like this is done and it would be nice if you took a look. I'm really sorry about the long wait. |
Yup, pretty happy with it. Go ahead. 🎉 |
|
This solves a problem that I encountered (along with the existing chain of issues) as a new user of the library. Thanks @annismckenzie for the initial work on the fork as well! |
|
Thanks a lot @annismckenzie! Great work on this! |
Awww, somehow this got lost in my inbox – thanks! 🙃 |
This allows state transitions to happen in enter state and after event callbacks by adding the possibility of "starting" a state machine and have it execute multiple state transitions in succession, given that no errors occur.
The equivalent code without this change:
Arguably, that’s bad because of several reasons:
outside the state machine.
state to transition to next (reinforces bullet point 2).
It is possible to fix a certain number of those problems but not all
of them, especially 2 and 4 but also 1.
The added test is green and uses both an enter state and an after event
callback. No other test case was touched in any way (besides enhancing the
context one that was added in the previous commit).
The relevant test is here: https://github.com/alfaview/fsm/blob/94fb353ef273319b14928aa3a04ab4e01a58d6da/fsm_test.go#L735-L774
This fixes #36. It also fixes #38. And it fixes #43. Finally, it fixes #61.