0Pricing
Flutter Mobile Development · レッスン

プロバイダーのスコープ、オーバーライド、ProviderObserver

機能ごとにプロバイダーのスコープを設定し、テストでオーバーライドして、デバッグのために状態変更を監視します。

「プロバイダーのスコープ、オーバーライド、ProviderObserver」はCoddyKit上の無料Flutter Mobile Developmentレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはFlutter Mobile Development学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Scoping, Overrides, and Observation Matter

Riverpod providers are global declarations, but their values don't have to be. Three powerful tools let you control and inspect provider state:

  • Scoping — give a provider a different value for one part of the widget tree (e.g. per feature, per item in a list).
  • Overrides — replace a provider's implementation, most often in tests to inject fakes.
  • ProviderObserver — a hook that fires on every provider add/update/dispose, perfect for logging and debugging.

In this lesson you'll learn to scope providers per feature, override them in tests, and observe state changes. These are the techniques that make a large Flutter app testable and debuggable.

The ProviderScope at the Root

Every Riverpod app is wrapped in a single ProviderScope at the root. This widget creates the ProviderContainer that stores all provider state.

The overrides parameter on ProviderScope is the entry point for both scoping and testing. By default it's empty and every provider uses its declared body.

void main() {
  runApp(
    const ProviderScope(
      // No overrides yet — every provider uses its default body.
      child: MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(home: HomeScreen());
  }
}

Scoping a Provider Per Feature

Sometimes a sub-tree needs a different value for a provider than the rest of the app. You do this by wrapping that sub-tree in a nested ProviderScope with an override.

A classic use case: a details screen that should expose the currently selected item to all its descendants without passing it through constructors.

First, declare a placeholder provider that throws — it must always be overridden before use:

// A provider that holds the current product id.
// It has no default value: callers MUST override it.
final currentProductIdProvider = Provider<String>(
  (ref) => throw UnimplementedError(
    'currentProductIdProvider must be overridden in a ProviderScope',
  ),
);

Overriding With a Value in a Nested Scope

When you push the details route, wrap it in a nested ProviderScope and use overrideWithValue to inject the selected id. Every widget below can now read currentProductIdProvider as if it had a real value.

This keeps your widgets decoupled: a ProductTitle deep in the tree never needs the id passed down — it just reads the scoped provider.

void openDetails(BuildContext context, String productId) {
  Navigator.of(context).push(
    MaterialPageRoute(
      builder: (_) => ProviderScope(
        overrides: [
          currentProductIdProvider.overrideWithValue(productId),
        ],
        child: const ProductDetailsScreen(),
      ),
    ),
  );
}

class ProductTitle extends ConsumerWidget {
  const ProductTitle({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final id = ref.watch(currentProductIdProvider);
    return Text('Product #$id');
  }
}

How Scope Resolution Works

When a widget reads a provider, Riverpod walks up the widget tree looking for the nearest ProviderScope that overrides it. If none overrides it, the value comes from the root container.

  • A provider's state lives in the scope where it is overridden.
  • Two sibling nested scopes each get their own independent copy of an overridden provider.
  • Providers that are not overridden are still resolved from the root — nesting a scope does not duplicate everything.

This is why scoping is cheap: only the overridden providers are re-created per scope.

overrideWith vs overrideWithValue

There are two ways to override a provider:

  • overrideWithValue(x) — replace the exposed value with a constant. Works on any provider whose value type matches. Great for injecting a fixed id or a pre-built fake.
  • overrideWith((ref) => ...) — replace the provider's body with a new build function (or a different Notifier). Use this when you need the override to compute something or depend on other providers.

For a NotifierProvider, you override with a factory that returns a fake notifier of the same base type:

// Real provider
final cartProvider = NotifierProvider<CartNotifier, List<String>>(
  CartNotifier.new,
);

// Fake used in tests
class FakeCartNotifier extends CartNotifier {
  @override
  List<String> build() => ['seed-item'];
}

final overrides = [
  cartProvider.overrideWith(FakeCartNotifier.new),
];

Overriding Providers in Tests

The most common reason to override is testing. In a widget test, wrap the widget under test in a ProviderScope and inject fakes so no real network or database is hit.

This makes the test deterministic: the repository provider is replaced with an in-memory fake.

testWidgets('shows product title from fake repo', (tester) async {
  await tester.pumpWidget(
    ProviderScope(
      overrides: [
        productRepositoryProvider.overrideWithValue(FakeProductRepository()),
        currentProductIdProvider.overrideWithValue('42'),
      ],
      child: const MaterialApp(home: ProductDetailsScreen()),
    ),
  );

  await tester.pumpAndSettle();
  expect(find.text('Product #42'), findsOneWidget);
});

Testing Logic With a Bare ProviderContainer

For pure logic tests you don't even need widgets. Create a ProviderContainer directly, pass overrides, and read providers from it. Always call addTearDown(container.dispose) so state is cleaned up between tests.

Use container.read to get a value once, and container.listen to assert on state transitions.

test('cart starts empty then adds an item', () {
  final container = ProviderContainer(
    overrides: [
      // inject a deterministic clock, repo, etc.
    ],
  );
  addTearDown(container.dispose);

  expect(container.read(cartProvider), isEmpty);

  container.read(cartProvider.notifier).add('book');
  expect(container.read(cartProvider), ['book']);
});

Introducing ProviderObserver

ProviderObserver is a class with lifecycle callbacks that Riverpod invokes for every provider in a container. Override the methods you care about:

  • didAddProvider — a provider was initialized for the first time.
  • didUpdateProvider — a provider's value changed (gives you previous and new value).
  • didDisposeProvider — a provider was disposed.
  • providerDidFail — a provider threw during build.

You attach observers via the observers list on ProviderScope or ProviderContainer.

Writing a Logging Observer

A logging observer is the fastest way to see exactly when and why your state changes. Each callback receives the ProviderBase and a ProviderContainer, so you can read names and values.

Use provider.name ?? provider.runtimeType for readable output — give your providers names to make logs meaningful.

class LoggerObserver extends ProviderObserver {
  @override
  void didUpdateProvider(
    ProviderBase<Object?> provider,
    Object? previousValue,
    Object? newValue,
    ProviderContainer container,
  ) {
    debugPrint(
      '[UPDATE] ${provider.name ?? provider.runtimeType}: '
      '$previousValue -> $newValue',
    );
  }

  @override
  void providerDidFail(
    ProviderBase<Object?> provider,
    Object error,
    StackTrace stackTrace,
    ProviderContainer container,
  ) {
    debugPrint('[FAIL] ${provider.name}: $error');
  }
}

Attaching the Observer

Pass your observer to the root ProviderScope via the observers list. From then on, every state change in the entire app flows through it — invaluable for debugging mysterious rebuilds.

You can attach multiple observers (e.g. one for logging, one for analytics). In tests, you can attach an observer to a ProviderContainer to assert on the sequence of updates.

void main() {
  runApp(
    ProviderScope(
      observers: [LoggerObserver()],
      child: const MyApp(),
    ),
  );
}

// Give providers names so observer logs are readable:
final counterProvider =
    NotifierProvider<CounterNotifier, int>(CounterNotifier.new, name: 'counter');

Quick Check: Per-Item Scoping

You render a list of products. Tapping one opens a details screen, and many widgets deep in that screen need the selected product's id. You want to avoid passing the id through every constructor, and each open details screen should be independent.

Recap

You learned three complementary techniques for controlling and inspecting Riverpod state:

  • Scoping — wrap a sub-tree in a nested ProviderScope and override a placeholder provider so descendants read a feature- or item-specific value without constructor plumbing.
  • Overrides — use overrideWithValue for constants and overrideWith for replacing a build function or Notifier. In tests, inject fakes via ProviderScope (widget tests) or a bare ProviderContainer with addTearDown(container.dispose) (logic tests).
  • ProviderObserver — attach observers through the observers list to log didAddProvider, didUpdateProvider, didDisposeProvider, and providerDidFail. Name your providers for readable diagnostics.

Together these make a large Flutter app modular, testable, and debuggable.

よくある質問

「プロバイダーのスコープ、オーバーライド、ProviderObserver」レッスンは無料ですか？

はい。「プロバイダーのスコープ、オーバーライド、ProviderObserver」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Flutter Mobile Developmentコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Flutter Mobile Developmentコースには全4レッスンが含まれています。

「プロバイダーのスコープ、オーバーライド、ProviderObserver」で何を学びますか？

機能ごとにプロバイダーのスコープを設定し、テストでオーバーライドして、デバッグのために状態変更を監視します。 ブラウザで直接実行するハンズオンコードでFlutter Mobile Developmentを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Flutter Mobile Developmentを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFlutter Mobile Developmentは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。

「プロバイダーのスコープ、オーバーライド、ProviderObserver」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFlutter Mobile Developmentレッスンでコードを書いて実行できますか？

はい。すべてのFlutter Mobile Developmentレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. ProviderからRiverpodへ：レガシー状態管理の移行
  2. riverpod_generatorと@riverpodによるコード生成
  3. AsyncNotifierとFutureProviderのデータパイプライン
  4. プロバイダーのスコープ、オーバーライド、ProviderObserver
← Flutter Mobile Developmentに戻る