The Rise of the State Machines
summary
A Kotlin DSL models a Shopify login flow of about six states (empty, typing, loading, authenticated, error, no-network) as a unidirectional state machine that moves transitions into state definitions, isolates side effects into processors, and replaces ad-hoc MVI stores. The implementation enforces compile-time safety so invalid actions won’t compile, makes the navigation a readable code-as-diagram, isolates network calls for easy testing, and takes about a week to prototype—works in practice and reduces impossible-to-reproduce crashes.
AI-written summary · about
chapters (15)
- 0:00Introduction and problem
- 2:28Basic login states
- 3:32MVI architecture overview
- 6:46Handling side effects
- 7:50MVI global store issues
- 9:38State machines explained
- 13:49Pros and cons of MVI
- 17:42State machines pros and cons
- 19:28Desired global flow diagram
- 20:12Kotlin DSL for flow
- 23:00Separating state logic
- 25:25Implementing transitions
- 28:20Adding new transitions
- 29:02Linking to UI
- 31:51Summary and solutions
related talks
47mThe Rise of the State Machines: An Introduction to Predictable State Container–Based Architectures for Your Android Apps
40mCoding Complex App Logic, Visually
20mSetState, We Need to Talk!
24mLeveraging the Power of State Machines in Swift
41mStateMachine Architecture Based on MVI: Combining KMM, Jetpack Compose and SwiftUI
38mInto the Visual World of State Machines
28mState machines for frontend state management
37mReactive State Machines and Statecharts