riverpod-from-provider

Riverpod — Migrating from Provider

Motivation

Riverpod was created as a successor to Provider, addressing InheritedWidget limitations:

• Same type: Provider can't have two Provider<Item> in the tree (only the nearest is found). Riverpod has no such limit; providers are identified by variable, not type.
• Combining providers: ProxyProvider is tedious and error-prone. In Riverpod, use ref.watch inside a provider to depend on others; composition is straightforward.
• AsyncValue: Riverpod can expose previous data while loading (e.g. show old list + loading indicator). Provider doesn't offer this cleanly.
• Safety: Provider can throw ProviderNotFoundException at runtime. Riverpod avoids this by design.
• Disposal: Provider can't react when consumers stop listening; scoping is tricky. Riverpod offers autoDispose and ref.keepAlive for clear lifecycle and caching.
• Parameters: Riverpod's .family gives type-safe, parameterized providers with per-parameter state; with autoDispose, state is disposed when unused. Equivalent in Provider is impractical.
• Testing: With Provider you must re-define providers per test. With Riverpod, override with overrides to mock.
• Side effects: Riverpod offers ref.listen for reacting to changes (e.g. navigation, snackbars). Provider has no built-in equivalent.

The main API change: use ConsumerWidget (and WidgetRef) instead of StatelessWidget, and ref.watch / ref.read instead of context.watch / context.read.

---

Quickstart

• Read the Riverpod getting started guide (riverpod-getting-started) and try a small example.
• Migrate incrementally. You can run Provider and Riverpod side by side (use import aliases if needed).

Start with ChangeNotifierProvider

Keep existing ChangeNotifier classes and wrap them in Riverpod's ChangeNotifierProvider:

final myNotifierProvider = ChangeNotifierProvider<MyNotifier>((ref) => MyNotifier());