How does Riverpod differ from Provider?
Short Answer
Riverpod is a redesign by the same author as Provider that removes the dependency on BuildContext and the widget tree, catching errors at compile time instead of runtime, and making providers globally accessible and easily testable.
Provider relies on InheritedWidget, which means lookups can fail at runtime if you call `context.watch<T>()` above the provider in the tree, or if the type is wrong — these show up as runtime exceptions. Riverpod declares providers as plain top-level (or class) objects, completely decoupled from BuildContext, so the compiler can catch a missing or mistyped provider before you even run the app.
Riverpod also makes providers easy to override for testing (e.g. swapping a real repository provider for a mock one in a test's `ProviderScope`), supports automatic disposal of state that's no longer being listened to (`autoDispose`), and has first-class support for async state via `FutureProvider`/`StreamProvider` with built-in loading/error/data states.
Common Mistakes
- ×Assuming Riverpod is just "Provider 2.0" with the same mental model — its decoupling from BuildContext changes how you structure dependencies.
- ×Not using `autoDispose` where appropriate, leading to providers that never get cleaned up.
Interview Tips
- →Mention that Riverpod is a separate package (not part of Flutter SDK), unlike some assume.
Related Questions
What is the Provider package and how does it work?
Provider is a wrapper around Flutter's InheritedWidget that makes it easy to expose and listen to a piece of state from anywhere below it in the widget tree, and to rebuild only the widgets that actually depend on it.
What is the BLoC pattern in Flutter?
BLoC (Business Logic Component) separates UI from business logic by having the UI dispatch Events into a Bloc, which processes them and emits new States that the UI rebuilds from — all communication happens through a strict, unidirectional stream of Events and States.