State Machines in the React Ecosystem

i’d love if there was a “state machine” solution in the React ecosystem that isn’t “create objects that talk to each other outside of React, and sync their state into React on change”. this architecture can’t integrate with and benefit from Suspense and Transitions.

— дэн (@dan_abramov) April 8, 2023

a solution like this doesn’t need to be React-specific. it only means that your core should not export “machine constructors” with methods like “send” etc. it should export pieces that can be “interpreted” by reducers, effects, and event handlers. whether React or not.

— дэн (@dan_abramov) April 8, 2023

then your useMachine() Hook in the react integration would be a regular useState or a useReducer that wires up that core logic to your component, but lets *react* drive the actual state changes. let your component *be* the state machine, not *talk to* a state machine.

— дэн (@dan_abramov) April 8, 2023

here’s a super simple way to figure out if your state machine library is designed in the way that enables this. take examples on this page, and replace “setState”s with “send”s, and “useState”s with “useMachine”s. does it still work? then you’re golden. 💯 https://t.co/qIS3tVTmnf

— дэн (@dan_abramov) April 8, 2023

i’ve been trying to convince existing solutions to explore this way, and it’s been a challenge. i’m sure a lot of this is due to needing to support existing APIs, or perhaps by not seeing the value, or perhaps by feeling React “wants too much”. that’s ok.

this is for new folks.

— дэн (@dan_abramov) April 8, 2023

Suspense and Transitions are no longer a weird niche thing. for example, Next 13 App Router is deeply integrated with them. see https://t.co/IZGPbluSwU for a concrete example of how elegantly it solves tricky coordination problems in async UI. an opportunity for new lib authors.

— дэн (@dan_abramov) April 8, 2023