In Riverpod 3, what does autoDispose do, and why does a product-detail screen refetch after you leave and reopen it?
answer
- state tied to having listeners
- last listener leaves, onCancel
- disposal scheduled, not instant
- default lifetime is the container
- isAutoDispose: true or .autoDispose
basics
~20 sautoDispose destroys a provider's state once nothing listens to it any more. Leaving the product screen removes its last listener, so the state and fetched product are dropped; reopening reads the provider again, which rebuilds it and refetches.
solid answer
~40 sBy default a Riverpod provider keeps its state for as long as its `ProviderContainer` - in Flutter, the `ProviderScope` - lives. `autoDispose`, enabled with `FutureProvider.autoDispose(...)` or `isAutoDispose: true`, ties the state to having listeners instead. When the last `ref.watch` or `ref.listen` goes away, `onCancel` runs and a disposal is scheduled; if no listener returns before it runs, the state is destroyed and `onDispose` runs. The next read builds it from scratch. So a product-detail screen that watches `productDetailProvider('p-42')` refetches when reopened: popping the route removed the only listener. That is usually the point - freeing memory and cancelling work - and if you want a short cache, `ref.keepAlive` adjusts it. Families should almost always be autoDispose, or every argument ever used stays in memory.
code
dart · 26 linesimport 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
final productDetailProvider =
FutureProvider.autoDispose.family<Product, String>((ref, productId) async {
final api = ref.watch(catalogApiProvider);
ref.onCancel(() => debugPrint('no listeners for $productId'));
ref.onDispose(() => debugPrint('disposed $productId'));
return api.fetchProduct(productId);
});
class ProductDetailPage extends ConsumerWidget {
const ProductDetailPage({super.key, required this.productId});
final String productId;
@override
Widget build(BuildContext context, WidgetRef ref) {
final product = ref.watch(productDetailProvider(productId));
return switch (product) {
AsyncData(:final value) => Text(value.name),
AsyncError() => const Text('Could not load product'),
_ => const CircularProgressIndicator(),
};
}
}go deeper
Remember the rule: default providers live as long as ProviderScope, autoDispose ones only while something listens. Know how to add .autoDispose.
Walk through onCancel, the scheduled disposal and onDispose, and explain why a quick hand-off between two listeners does not lose the state.
Decide per provider whether it should be app-wide or screen-scoped, and catch families without autoDispose as memory leaks in review.
Set a default policy - autoDispose for screen data and families, explicit exceptions for app-wide services - so cache lifetimes are a deliberate design choice.
## Default lifetime versus autoDispose A Riverpod provider's **state** lives in a `ProviderContainer`. In a Flutter app that container belongs to the `ProviderScope` at the root, so without any modifier a provider, once read, keeps its state for the life of the app. It is reset only if it is invalidated or if a watched dependency changes. **`autoDispose`** changes that rule: the state lives only while something is listening to it. | | Default provider | autoDispose provider | |---|---|---| | State created | on first read | on first read | | State kept while unlistened | yes, until container disposal | no | | Rebuilt when a watched dependency changes | yes | yes | | Typical use | app-wide settings, clients, session | screen data, search results, anything keyed by an argument | The docs stress one point: enabling or disabling automatic disposal has no effect on recomputation. A recomputed provider always destroys its previous state. ## How to opt in Without code generation: - the modifier: `FutureProvider.autoDispose<Product>(...)`, chainable with a family as `FutureProvider.autoDispose.family<Product, String>(...)`; - or the constructor flag: `Provider<String>(isAutoDispose: true, (ref) => ...)`. With `riverpod_generator`, generated providers are auto-dispose by default and the annotation opts out; that is the codegen topic. ## When exactly state is destroyed Riverpod tracks listeners created by `ref.watch` and `ref.listen`: 1. The last listener is removed - the product screen is popped and its `ConsumerWidget` unmounts. 2. The provider becomes inactive and its **`ref.onCancel`** callbacks run. 3. A disposal is **scheduled**, not performed on the spot. The docs describe it as waiting one frame. 4. When the scheduled task runs, Riverpod checks again. If a listener came back, or a `ref.keepAlive` link is open, nothing happens. 5. Otherwise the state is destroyed and **`ref.onDispose`** callbacks run - cancel the HTTP request, close the stream controller. Step 4 is why navigating from one screen to another that watches the same provider does not cause a refetch: the new listener arrives before the disposal runs. ## Why the product screen refetches ```dart final productDetailProvider = FutureProvider.autoDispose.family<Product, String>((ref, productId) async { final api = ref.watch(catalogApiProvider); return api.fetchProduct(productId); }); ``` The detail screen is the only listener of `productDetailProvider('p-42')`. Popping it removes that listener, the state is disposed, and reopening the screen creates a fresh state, which runs the fetch again. Without `autoDispose`, the product would stay cached for the rest of the session - and so would every other product the user ever opened. ## Choosing - **Use autoDispose** for screen-scoped data, anything parameterised by a family argument, and providers holding resources such as stream subscriptions or timers. - **Skip it** for app-wide objects - an API client, the current user - that should survive navigation. - **Want a short cache in between?** Keep `autoDispose` and open a `ref.keepAlive()` link, closing it after a delay. ## Riverpod 3 cleanup In 2.x every class had an auto-dispose twin (`AutoDisposeNotifier`, `AutoDisposeRef`, ...). Riverpod 3 removed those interfaces: an auto-dispose notifier extends plain `Notifier`, and the modifier lives only on the provider.
- If screen A pushes screen B and both watch the same autoDispose provider, is the state disposed during the transition?No. The state is disposed only when it has no listeners at all. While both routes are mounted, both widgets listen. Even if A were removed before B mounted, disposal is scheduled rather than immediate, and Riverpod checks again before disposing, so a listener that arrives in time keeps the state.
- Why do the Riverpod docs recommend autoDispose for every family?A family keeps one state per argument. Without autoDispose, every product id, search query or page number ever requested stays in memory until the `ProviderScope` is disposed - effectively a leak that grows with use. With autoDispose, each argument's state disappears once no widget or provider listens to it.
saying these in an interview costs you the question
- autoDispose providers are rebuilt every time the widget rebuilds
- State is destroyed the instant the last listener is removed
- Without autoDispose the state is freed when the screen is popped
- autoDispose also prevents the provider from recomputing when dependencies change
- In Riverpod 3 an auto-dispose notifier must extend AutoDisposeNotifier