Architectural Thinking on Flutter State Management
summary
Compares six state approaches (setState, Riverpod, BLoC, MobX, Redux, GetIt) against seven clear criteria: simplicity, agility, scalability, testability, documentation, activity, and code coverage. Builds an MJ Coffee prototype in two days and chooses setState because it minimizes learning and delivers the product on schedule; notes that setState works for local UI state but costs maintainability if app grows. Recommends architecting layered boundaries so state solutions can be swapped later.
AI-written summary · about
chapters (15)
- 0:00Start
- 0:16State Management
- 1:09Managing the State
- 2:48Architectural Thinking
- 12:40The Breeds of Knowledge
- 13:20Triple Pattern
- 14:17Choosing State Management
- 16:35App State
- 21:32Functional Programming Approaches
- 24:05Code Coverage
- 25:37Scalability
- 26:54Performance
- 36:15Code Generation
- 41:22State Management Is Only One Part of Your Application
- 44:18Best State Management Package
related talks
44mState Management in Flutter
41mThe Battle of State Management in modern frontend applications
57mThe State of State
18mState Management — One Meta-Model to Rule Them All
23mThe two types of state management
22mFlutter State Smackdown: Comparing BLoC, Provider, Riverpod
19mA humble approach to Flutter app architecture
40mReact State – The Good, the Bad and the Ugly