Flutter Mobile Development · Aula

Escopo de Provedores, Substituições e ProviderObserver

Defina o escopo dos provedores por recurso, substitua-os nos testes e observe alterações de estado para depuração.

Escopo de Provedores, Substituições e ProviderObserver é uma aula grátis de Flutter Mobile Development no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Flutter Mobile Development, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Flutter Mobile Development inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

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.

Perguntas Frequentes

A aula “Escopo de Provedores, Substituições e ProviderObserver” é grátis?

Sim — o texto completo de “Escopo de Provedores, Substituições e ProviderObserver” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Flutter Mobile Development, atualize para CoddyKit PRO. O curso de Flutter Mobile Development inclui 4 aulas no total.

O que vou aprender em “Escopo de Provedores, Substituições e ProviderObserver”?

Defina o escopo dos provedores por recurso, substitua-os nos testes e observe alterações de estado para depuração. Você pratica Flutter Mobile Development com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Flutter Mobile Development?

Nenhuma experiência prévia é necessária. Flutter Mobile Development no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.

Quanto tempo leva a aula “Escopo de Provedores, Substituições e ProviderObserver”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Flutter Mobile Development?

Sim. Cada aula de Flutter Mobile Development inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

Do Provider ao Riverpod: Migração de Estado Legado
Geração de Código com riverpod_generator e @riverpod
Pipelines de Dados com AsyncNotifier e FutureProvider
Escopo de Provedores, Substituições e ProviderObserver

← Voltar para Flutter Mobile Development