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
Copy file name to clipboardExpand all lines: packages/overmind-website/guides/intermediate/06_statecharts.md
+28Lines changed: 28 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,26 @@ As you can see we have defined what transition states our login flow can be in a
37
37
38
38
Since our initial state is **LOGIN**, a call to actions defined in the other transition states would simply be ignored.
39
39
40
+
## Transitions
41
+
42
+
If you are familiar with the concept of statemachines you might ask the question: *"Where are the transitions?"*. In Overmind we use actions to define transitions instead of having explicit transition types. That means you think about statecharts in Overmind as:
43
+
44
+
```
45
+
TRANSITION STATE -> ACTION -> NEW TRANSITION STATE
46
+
```
47
+
48
+
as opposed to:
49
+
50
+
```
51
+
TRANSITION STATE -> TRANSITION TYPE -> { NEW TRANSITION STATE, ACTION }
52
+
```
53
+
54
+
This approach has three benefits:
55
+
56
+
1. It is more explicit in the definition that a transition state configures what actions are available
57
+
2. When typing your application the actions already has a typed input, which would not be possible with a generic **transition** action
58
+
3. It is simpler concept both in code and for your brain
59
+
40
60
## Conditions
41
61
42
62
In our chart above we let the user log in even though there is no **username** or **password**. That seems a bit silly. In statecharts you can define conditions. These conditions receives the state of the configuration and returns true or false.
@@ -111,6 +131,14 @@ What to take notice of in this example is that we simply **spread** a chart into
111
131
112
132
In this example we also took advantage of the **entry** and **exit** hooks of a transition state. These also points to actions. When a transition is made into the transition state the **entry** will run. This behavior is nested. When an exit hook exists and a transition is made away from the transition state it will also run. This behivor is also nested of course.
113
133
134
+
## Devtools
135
+
136
+
The Overmind devtools understands statecharts. That means you are able to get an overview of available statecharts and even manipulate them directly in the devtools.
137
+
138
+

139
+
140
+
You will see what transition states and actions are available, and active, within each of them. You can click any active action to select it and click again to execute, or insert at payload at the top before execution.
141
+
114
142
## Summary
115
143
116
144
The point of statecharts in Overmind is to give you an abstraction over your configuration that ensures the actions can only be run in certain states. Just like operators you can choose where you want to use it. Maybe only one namespace needs a statechart, or maybe you prefer using it on all of them. The devtools has its own visualizer for the charts, which allows you to implement and test them without implementing any UI.
0 commit comments