Question 1

What does autoDispose do, and when do you turn it off?

Accepted Answer

autoDispose ties a state's lifetime to how many users it has: when no listener remains, the state is cleared. The sequence the docs describe: the counter hits zero → ref.onCancel → a one-frame wait → if still unused, ref.onDispose and the state is destroyed. Turning it off (keepAlive) is justified for: State needed app-wide — the auth session, remote config, feature flags. Expensive, rarely changing data — reloading on every navigation is latency for the user. Keeping it on is justified for: Parameterised providers — the docs recommend it directly, because state accumulates per argument combination. Screen-scoped data — a detail page, a search result. The strongest answer sits in the middle: autoDispose plus a conditional ref.keepAlive() caches successful results but not errors, and link.close() lets you expire that cache on a timer.

Question 2

What is family for and what traps does it have?

Accepted Answer

family lets you pass an argument to a provider: productProvider('sku-42'). Riverpod keeps separate state per argument — so it is both parameterisation and an argument-keyed cache. The traps: 1. The == trap — the argument is the cache key. An object without ==/hashCode creates a new key every time: the cache never hits and every rebuild fires a new request. Fix: a record, value types, or an immutable model via freezed. 2. Memory — combined with keepAlive, state accumulates per argument; the docs recommend automatic disposal for parameterised providers. 3. Multiple arguments — without code generation you are limited to one positional argument, while codegen allows named, optional and defaulted parameters. That is one of codegen's practical advantages. 4. Misuse — use family instead of creating providers dynamically; the DO/DON'T page bans dynamic creation as a cause of memory leaks.

Question 3

Data reloads every time the user leaves and returns to a screen. What could cause it and how would you fix it?

Accepted Answer

Build the diagnosis in steps: 1. Is autoDispose the expected behaviour here? A codegen provider is autoDispose by default — when the screen closes no listener remains and the state is destroyed. So this is a configuration question, not a bug. 2. Does the data actually need to be fresh? For prices, stock or a notification count, reloading is right. For a static catalogue or config it is waste. 3. Pick a caching strategy: keepAlive: true if it is needed app-wide; ref.keepAlive() plus link.close() for a time-based expiry if you only want to hold a successful result for a while. 4. Check the family argument — if it is not stable under ==, the cache never hits and the problem persists regardless of autoDispose. 5. Protect the UX — when a reload is required, render the previous value from the AsyncValue with a small indicator on top so the screen doesn't jump. Close by noting this is usually a symptom of an undocumented caching policy; the team should decide up front how long each kind of data lives.

Situation	Recommendation	Reason
The provider takes parameters (a family)	Keep autoDispose enabled	The docs' recommendation: otherwise state accumulates for every argument combination
Configuration or auth needed app-wide	`@Riverpod(keepAlive: true)`	Reloading on every navigation makes no sense
A heavy request's result, but only when it succeeds	autoDispose plus a conditional `ref.keepAlive()`	Errors are not cached while successful results are
A screen's temporary state (a filter, a selection)	autoDispose — or not a provider at all	The DO/DON'T page advises against providers for ephemeral state

autoDispose, keepAlive and family

📚 Sources and documentation