State Manager Architecture
summary
Presents a state manager design that combines reactive dependency tracking with atomic, transaction-like updates to prevent inconsistent UI states. Describes ryadom, a library implementing this approach (supporting immutable and mutable transactions, time-travel/persistence, and separation of pure computations from side effects), explains push vs pull evaluation and hot/cold observables, and covers pitfalls like cycles, glitches, memory leaks while warning about careful async transaction design and noting production use at Yandex and in finance.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 3:55Reactive programming
- 10:41What are data
- 13:37Cache and state
- 15:48State and finite state machines
- 18:16Transactions and atomicity
- 22:12Transaction approach benefits
- 27:16Side effects issues
- 29:01Zombie subscribers and transactions
- 33:41Cold and hot streams
- 35:48Conclusion and library comparison
- 36:11Q&A
related talks
52mState management beyond the libraries
18mState Management — One Meta-Model to Rule Them All
27mCrafting state management – A principle based architecture
41mThe Battle of State Management in modern frontend applications
14mState management without pain
37mApplication state management
30mManaging State Management
36mModern React and the case for Reactive State Management