State orchestration using State Machines

Farzad Yousefzadeh


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


👉🏻 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


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


Focus actor: register focusable items and focus them on demand by message passing


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, fromObservable

Kiitos ❤️