Flutter Mobile Development · Lezione

Ambito dei provider, override e ProviderObserver

Definisca l’ambito dei provider per funzionalità, li sostituisca nei test e osservi i cambiamenti di stato per il debugging.

Lezione 4 di 413 passaggi

Ambito dei provider, override e ProviderObserver è una lezione Flutter Mobile Development gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Flutter Mobile Development, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Flutter Mobile Development include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

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.

Rispondi nella lezione interattiva

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.

Gratis per iniziare

Impara Dart con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi: 22
Lezioni: 88

Inizia a imparare gratis Visualizza il corso completo

Domande Frequenti

La lezione «Ambito dei provider, override e ProviderObserver» è gratuita?

Sì — il testo completo di «Ambito dei provider, override e ProviderObserver» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Flutter Mobile Development, passa a CoddyKit PRO. Il corso Flutter Mobile Development include 4 lezioni in totale.

Cosa imparerò in «Ambito dei provider, override e ProviderObserver»?

Definisca l’ambito dei provider per funzionalità, li sostituisca nei test e osservi i cambiamenti di stato per il debugging. Eserciti Flutter Mobile Development con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Flutter Mobile Development?

Non è richiesta alcuna esperienza precedente. Flutter Mobile Development su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Ambito dei provider, override e ProviderObserver»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Flutter Mobile Development?

Sì. Ogni lezione Flutter Mobile Development include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

Da Provider a Riverpod: migrazione dello stato legacy
Generazione del codice con riverpod_generator e @riverpod
Pipeline di dati con AsyncNotifier e FutureProvider
Ambito dei provider, override e ProviderObserver

← Torna a Flutter Mobile Development