State orchestration using State Machines
Farzad Yousefzadeh
@farzad_yz
Stately: Diagrams to the next level
Finite State Machine
type State = {
isLoading: boolean;
accounts: Account[];
error?: string;
};type State=
| "Idle"
| "Loading"
| "Completed"
| "Failed";Think in STATES
type Data = {
accounts: any[];
errorMessages?: string;
}Finite state
Infinite state
XState
👉🏻 State machines and Statecharts
👉🏻 TypeScript
👉🏻 Framework agnostic
👉🏻 Frontend and Backend
👉🏻 Based on SCXML standard
👉🏻 JSON config that ports to other languages
Model a Carousel
State orchestration
Actors
Canvas item actor: selection, highlighting, per item commands
Canvas actor: permissions (read-only), modes (embed)
Keyboard actor: delete item, select all items, copy pasting items
URL actor: update query params, navigate, feed initial data to the canvas
Ad-hoc UI actors: Toast actor, Popover actor
Supervisor
Focus actor: register focusable items and focus them on demand by message passing
Actors
Component tree vs Actor tree
General benefits of state machines
👉🏻 See breadth of features better
👉🏻 Event based architecture
👉🏻 Discover edge cases upfront
👉🏻 Focus on behavior than implementation
👉🏻 Visual model: onboarding, learning code, documentation
👉🏻 Test generation and property based testing
When to use state machines
👉🏻 Model a new feature
👉🏻 Refactor an existing feature
👉🏻 Learn a feature by modeling it from a higher level
👉🏻 Test a feature by modeling it for the test scenarios
Where to use State machines
👉🏻 UI components
👉🏻 Server sequences and workflows like continuous integration
👉🏻 Server controllers or cloud functions where there's asynchronous code and decision trees involved
👉🏻 State orchestration so different machines and actors can pass messages
👉🏻 Not all actors have to be a state machines
👉🏻 XState:fromPromise, fromCallback, fromReducer, fromObservableKiitos ❤️