TAMING UI COMPLEXITY WITH TYPED STATES MACHINES 

No content

‣ Software developer @ ‣ Doing React with Typescript @work ‣ Played with Elm @home ABOUT ME BOGDAN ZAHARIA @zaboco 

http://bit.ly/taming-ui 

POTENTIALLY ASKED QUESTIONS ‣ Do I need to know about state machines? ‣ NO ‣ Do I need to know Typescript? ‣ A LITTLE PAQ 

in the real world State machines 

STATES ‣ Idle 1. INSERT_CAN ‣ Loaded 2. PRESS_BUTTON ‣ Recycling 2.5 WAIT_FOR_RECYCLING ‣ Done 3. COLLECT_REWARD ‣ Idle (again) 

Idle Loaded INSERT_CAN Recycling PRESS_BUTTON Done COLLECT_REWARD IDEAL WAIT_FOR_RECYCLING 

Idle Loaded INSERT_CAN Recycling PRESS_BUTTON Done WAIT_FOR_RECYCLING COLLECT_REWARD REAL PRESS_BUTTON COLLECT_REWARD " WAIT_FOR_RECYCLING PRESS_BUTTON PRESS_BUTTON INSERT_CAN INSERT_CAN INSERT_CAN 

But in software we can do better 

WHAT ABOUT XSTATE? ‣ Great library, a lot of features. ‣ Can specify states and transitions: const recyclingMachine = Machine({ initial: "Idle", states: { Idle: { on: { INSERT_CAN: "Loaded" } }, "// ""... } }); ‣ Written in Typescript ‣ Does not enforce transitions recyclingMachine.transition('INSERT_CAN') "// Loaded recyclingMachine.transition('INSERT_CAN') "// still Loaded 

WHAT ABOUT REDUX? What about it? Redux is not a state machine Or is it? Maybe Redux is a machine with 1 state. 

But… Redux already uses “state” We’ll just call it Model 

Let’s see an example 

No content

function reducer( model: AppModel = {}, action: AppAction ): AppModel { switch (action.type) { case 'LOGIN_SUCCESS': return { name: action.payload }; case 'LOGIN_ERROR': return { error: action.payload }; case 'LOGOUT': return {}; case 'NAME_TO_LOWERCASE': return { name: model.name.toLowerCase() } } } OUR REDUX APP type AppModel = { error"?: string; name"?: string; }; type AppAction = | { type: 'LOGIN_SUCCESS'; payload: string; } | { type: 'LOGIN_ERROR'; payload: string; } | { type: 'NAME_TO_LOWERCASE' } | { type: 'LOGOUT' }; ❗ 

Maybe we need to split the Model by state 

LoggedOut { error!?: string } LoggedIn { name: string } LOGIN_SUCCESS (string) LOGIN_ERROR (string) LOGOUT NAME_TO_LOWERCASE 

But how do we restrict transitions? 

View HOW UI IS HANDLED IN REDUX Store uses the model dispatch Machine transition OR XSTATE 

LoggedIn View WHAT IF WE INVERT THE CONTROL? Machine {name:string} LOGOUT or NAME_TO_LOWERCASE LoggedOut View {error!?:string} LOGIN_SUCCESS or LOGIN_ERROR 

Introducing typed-machine 

Demo Time ▶ 

NOT ONLY REACT ‣ A machine is abstract ‣ Needs adapters (e.g. MachineAdapter for React) ‣ Same machine used with different views/adapters ‣ Other implemented (more or less) adapters: ✓ Vue.js ✓ CLI ✓ Koa (server-side) 

No content

Thanks! @zaboco 

NEXT STEPS ๏ Update docs ๏ Scaling - machines inside machines (as model) [WIP] ๏ Async transitions (e.g. fetch requests) [WIP] x Routing x History - undo/redo x Time travel debugging x Eslint plugin (multiple dispatches, unreachable states) 

WHAT IF I DON’T WANT TO USE TYPESCRIPT ‣ TS is still JS, so typed-machine can be used with JS - (all the type guarantees are lost) ‣ Try XState or others ‣ Port typed-machine to Flow or Reason 

๏ Repo: https://github.com/zaboco/typed-machine/tree/ jsheroes-demo ๏ Related talk: “Making Impossible states impossible” ‣ https://youtu.be/IcgmSRJHu_8 LINKS