จาก Provider สู่ Riverpod: การย้ายสถานะแบบเดิม

The classic provider package solved dependency injection in Flutter, but it has real weaknesses you have probably hit in production:

• Runtime crashes — calling context.read<T>() for a type that was never provided throws a ProviderNotFoundException at runtime, not compile time.
• BuildContext coupling — you can only read providers where you have a BuildContext.
• No combining — depending on one ChangeNotifier from another is awkward and error-prone.

Riverpod is a rewrite by the same author. Providers are top-level globals that the compiler can verify, so a missing dependency becomes a compile error. This lesson walks you through migrating a legacy ChangeNotifier + Provider app to Riverpod 2.0, piece by piece.

Here is a typical legacy counter feature using ChangeNotifier. It exposes a value and a method that calls notifyListeners(). This is the pattern we will convert step by step.

Notice that the state (_count) and the mutation logic live together inside a class that extends ChangeNotifier.

In the old setup you register the model with ChangeNotifierProvider high in the widget tree, then read it via context.watch / context.read. The problem: if you forget to register it, the app compiles fine and crashes only when that screen opens.

Add flutter_riverpod to pubspec.yaml. The single most important wiring change is to wrap your app in a ProviderScope. This is the container that stores the state of every provider — it replaces the nest of ChangeNotifierProvider widgets at the root.

• Old: many provider widgets wrapping MyApp.
• New: one ProviderScope. Providers themselves are declared as globals, not in the tree.

Riverpod 2.0 introduces Notifier as the modern, type-safe replacement for ChangeNotifier. The differences:

• You hold state in a single state field instead of private fields + getters.
• You never call notifyListeners() — reassigning state rebuilds listeners automatically.
• The build() method returns the initial state.

Here is the migrated counter as a Notifier<int>:

Replace context.watch/context.read with a WidgetRef. The cleanest path is to make your widget a ConsumerWidget, which adds a ref parameter to build.

• ref.watch(provider) — subscribe and rebuild on change (use in build).
• ref.read(provider.notifier) — get the notifier to call methods (use in callbacks).

The most common migration bug is using the wrong access method. Map the old API to the new one carefully:

• context.watch<T>() → ref.watch(provider)  (rebuilds the UI)
• context.read<T>() in a callback → ref.read(provider.notifier)  (no rebuild)

Rule: never call ref.watch inside an onPressed callback — it will not behave as expected and can cause unnecessary rebuilds. Use ref.read for one-off actions, ref.watch for values displayed in the UI.

Legacy apps often load data inside a ChangeNotifier with manual isLoading/error booleans. Riverpod replaces all of that with AsyncValue and a FutureProvider — loading and error states are modeled for you.

The UI then uses AsyncValue.when to render data, loading, and error branches exhaustively.

In the old package, making one model depend on another required ProxyProvider and careful ordering. In Riverpod, a provider simply calls ref.watch on another provider inside its body. Dependencies are explicit, type-safe, and reactive.

Below, a derived provider recomputes automatically whenever cartProvider changes — no manual subscription, no notifyListeners chains.

You do not need Flutter to understand Riverpod's core idea: derived values recompute from their inputs. This pure-Dart snippet models the same fold-the-cart logic used in cartTotalProvider, so you can run and verify the math an online judge would compute.

You rarely rewrite a whole app at once. A safe, incremental plan:

• Wrap once: add ProviderScope at the root immediately — it coexists with the old provider package.
• Leaf-first: migrate self-contained features (settings, theme, counters) before tangled ones.
• Bridge if needed: a Riverpod provider can read legacy data, and a legacy widget can stay until its screen is converted.
• Convert widgets: change StatelessWidget→ConsumerWidget and StatefulWidget→ConsumerStatefulWidget as you touch each screen.
• Delete the old ChangeNotifierProvider and the provider dependency only when nothing references them.

Test your understanding of the most error-prone part of the migration.

You migrated a legacy ChangeNotifier + Provider feature to Riverpod 2.0:

• Wrapped the app in a single ProviderScope instead of nested provider widgets.
• Turned ChangeNotifier into a Notifier with a state field and no notifyListeners().
• Swapped context.watch/read for ref.watch (display) and ref.read(provider.notifier) (actions) inside a ConsumerWidget.
• Modeled async with FutureProvider + AsyncValue.when, and combined providers via ref.watch instead of ProxyProvider.
• Followed a leaf-first, incremental path so the two systems coexist during the transition.

The payoff: a compile-safe provider graph where a missing dependency is a build error, not a production crash.