State ManagementIntermediate30 XP3 min read
How do you structure multiple providers in a large Flutter app?
TL;DR: Use MultiProvider at the app root for global state. Feature-level providers are placed above the relevant route. Riverpod providers are global constants — no nesting needed.
Full Answer
As apps grow, provider placement strategy becomes important. Providers should be placed as low in the tree as possible while still being above all consumers.
- ▸App-level providers — auth, theme, localization: place at MaterialApp root
- ▸Feature-level providers — shopping cart, search: place above the feature routes
- ▸Screen-level providers — form state, loading flags: place above the screen widget
- ▸Riverpod: no placement needed — providers are global and autoDispose handles cleanup
🎯
In a go_router setup, wrap each route's builder with its own provider rather than hoisting everything to the root. This limits provider lifetime to the route's lifetime.
Code Examples
dartMultiProvider at app root
Output
ApiClient → UserRepository → AuthModel: dependency chain resolved correctly; all available app-wide
Common Mistakes
- ✗Placing all providers at the root even when only one screen needs them — wastes memory
- ✗Using context.read() in a create callback — throws if the provider isn't above it yet
Interview Tip
💡
Explain provider scoping strategy: global vs feature vs screen. This shows architectural thinking beyond just 'use Provider'.
#MultiProvider#Provider#Riverpod#architecture#DI