You don’t know MobX State Tree
summary
DAZN rebuilt a frontend for millions of users using MobX plus MobX State Tree and shows how MST actually enforces structure: models declare types, actions are the only way to mutate models, views are MobX computed getters, and runtime type checks throw if created state mismatches. Stores use store.create(initialState, environment) so environment is injected per tree which aids testing. MST emits snapshots are serializable enabling time travel and server persistence. Advice: prefer many small observers, choose one versus multiple root stores for snapshot and DI tradeoffs, and use composition to share behavior like mobile versus desktop scrolling.
AI-written summary · about
chapters (20)
- 0:00Intro
- 0:39Agenda
- 1:10MobX vs Mobile State
- 1:32MobX Engine
- 4:23Observable State
- 8:11State Tree
- 9:20Model
- 14:18Tree
- 18:09MobX Store
- 23:47Structure
- 25:17One Root Store
- 27:04Multiple Root Stores
- 29:34Stores Communication
- 30:06Default Approach
- 32:24Action Wrapper
- 33:49Dependency Injection
- 36:55Store Composition
- 38:45Mobile vs Desktop
- 41:10Derivation
- 42:04Summary
related talks
43mYou don’t know MobX State Tree
21mNext-gen React state management with MobX State Tree
41mmobx-state-tree, stop getting into all those states!
14mState management without pain
37mApplication state management
27mReact, But For Data
41mThe Battle of State Management in modern frontend applications
41mMobX, or: Going from Mutable to Immutable to Reactive State Management