Flutter Riverpod

1 roadmap 31 questionsupdated 2026-09-29

Riverpod 3 declares providers outside the widget tree, reads them through Ref, and caches, disposes and retries them automatically. Interviewers ask what it fixes about Provider.

▸ follow the flutter roadmap jump to the questions →

on this pageshow

guide

overview

~1 min

The hub follows the life of one piece of state. Declared provider types is the vocabulary: which kind of provider fits which job. Ref watch, read and listen is how widgets and other providers consume them. Auto-dispose and families decides how long state survives and how it is keyed. AsyncValue states is how loading, data and failure reach the screen. Annotation codegen is the @riverpod syntax that generates providers for you, and overrides and containers is how all of it gets tested.

Junior rounds ask you to pick a provider type and explain watch against read. Middle and senior rounds move to cache lifetimes, refresh behaviour, retries, scoped overrides and migrating a Riverpod 2 codebase. Learn the provider types and Ref first; everything else modifies them.

Riverpod is a state-management and dependency-injection library for Flutter and Dart, written by the author of Provider as its successor. Its state lives in provider objects declared at the top level of a file, outside the widget tree, and code reaches them through a `Ref`. Interviewers use it to test whether you can reason about *where state lives, who depends on it and when it goes away* — and the standard opening question is what Riverpod fixes about Provider: no runtime lookup failure because a provider sits above the wrong widget, no dependence on `BuildContext` for reading state, and several providers of the same type without wrapper classes. The hub follows the life of one piece of state. [Declared provider types](/topics/mob-riverpod-providers) is the vocabulary: which kind of provider fits which job. [Ref watch, read and listen](/topics/mob-riverpod-ref) is how widgets and other providers consume them. [Auto-dispose and families](/topics/mob-riverpod-modifiers) decides how long state survives and how it is keyed. [AsyncValue states](/topics/mob-riverpod-async) is how loading, data and failure reach the screen. [Annotation codegen](/topics/mob-riverpod-codegen) is the `@riverpod` syntax that generates providers for you, and [overrides and containers](/topics/mob-riverpod-testing) is how all of it gets tested. Junior rounds ask you to pick a provider type and explain `watch` against `read`. Middle and senior rounds move to cache lifetimes, refresh behaviour, retries, scoped overrides and migrating a Riverpod 2 codebase. Learn the provider types and `Ref` first; everything else modifies them.

primer

Providers are declarations, not widgets

A provider is a final, usually global, object that describes how to create a value. Declaring it creates nothing: the value comes into being the first time something reads it, inside a container that holds every provider's state. In Flutter that container comes from the ProviderScope at the root of the app. Because the declaration is plain Dart, a missing provider becomes a compile error instead of a runtime exception, and two providers returning the same type never collide.

Dependencies form a graph

A provider can watch other providers while it builds, so the app's state becomes a graph of derived values. When an upstream value changes, Riverpod rebuilds what depends on it and nothing else. Most design answers come down to drawing that graph: what is the source of truth, what is derived, and which edge causes a rebuild.

Lifetime is explicit

Every provider has a lifetime you choose. Auto-dispose ties state to its listeners, which frees memory but can surprise you with a refetch; keeping alive trades that back for a cache. A family multiplies one declaration into an instance per argument, which makes argument equality a correctness concern rather than a detail.

Async is a value, not a callback

Async providers do not make the UI await a Future. They expose an AsyncValue, a sealed type that is loading, data or error — and can carry the last good data while a new load runs. Screens render from that one value, which is why exhaustive handling and refresh semantics come up so often.

Mutation goes through notifiers

Read-only providers compute; notifiers own state that changes. A notifier's build produces the starting state and its methods replace it, so every change passes through one class that tests and other providers can reason about.

Tests swap the graph, not the code

Any provider can be overridden in a container or scope. A test replaces a repository at the edge of the graph and every provider above it sees the fake, while production code stays untouched and no separate injection framework is needed.

### Providers are declarations, not widgets A provider is a final, usually global, object that describes how to create a value. Declaring it creates nothing: the value comes into being the first time something reads it, inside a **container** that holds every provider's state. In Flutter that container comes from the `ProviderScope` at the root of the app. Because the declaration is plain Dart, a missing provider becomes a compile error instead of a runtime exception, and two providers returning the same type never collide. ### Dependencies form a graph A provider can watch other providers while it builds, so the app's state becomes a graph of derived values. When an upstream value changes, Riverpod rebuilds what depends on it and nothing else. Most design answers come down to drawing that graph: what is the source of truth, what is derived, and which edge causes a rebuild. ### Lifetime is explicit Every provider has a lifetime you choose. **Auto-dispose** ties state to its listeners, which frees memory but can surprise you with a refetch; **keeping alive** trades that back for a cache. A **family** multiplies one declaration into an instance per argument, which makes argument equality a correctness concern rather than a detail. ### Async is a value, not a callback Async providers do not make the UI await a `Future`. They expose an **`AsyncValue`**, a sealed type that is loading, data or error — and can carry the last good data while a new load runs. Screens render from that one value, which is why exhaustive handling and refresh semantics come up so often. ### Mutation goes through notifiers Read-only providers compute; **notifiers** own state that changes. A notifier's `build` produces the starting state and its methods replace it, so every change passes through one class that tests and other providers can reason about. ### Tests swap the graph, not the code Any provider can be **overridden** in a container or scope. A test replaces a repository at the edge of the graph and every provider above it sees the fake, while production code stays untouched and no separate injection framework is needed.

Provider: A top-level object that declares how to create one piece of state or one dependency. It holds no value itself; a container creates and caches the value on first read.
ProviderScope: The Flutter widget, placed at the root of the app, that owns the provider container. A nested scope can override providers for one subtree.
ProviderContainer: The object that stores provider states and their dependency graph. Flutter apps get one from ProviderScope; pure Dart code and unit tests create one directly.
Ref: The handle a provider or notifier receives to read other providers, register dispose callbacks and control its own lifetime.
WidgetRef: The Flutter-side counterpart of Ref, handed to consumer widgets so their build methods and handlers can read providers.
Notifier: A class that owns mutable provider state: build returns the initial state, and its methods assign new state. AsyncNotifier is the async variant.
AsyncValue: A sealed type with AsyncData, AsyncLoading and AsyncError cases, used by async providers so the UI can render every state from one value.
autoDispose: A modifier that destroys a provider's state once nothing listens to it any more, so the next read builds it from scratch.
keepAlive: A way to exempt a provider from auto-disposal, either permanently in its declaration or conditionally from inside its build.
Family: A provider that takes an argument and keeps a separate state per distinct argument value, such as one product per id.
Override: A replacement for a provider's creation logic or value inside one container or scope, used for tests, previews and subtree-specific values.
riverpod_generator: The build_runner code generator that turns functions and classes annotated with @riverpod into providers, deriving their names and kinds.

Start from the root. ProviderScope wraps the app and owns one container. When a consumer widget calls ref.watch on a provider for the first time, the container runs that provider's build, and the build may itself watch further providers — a repository, a settings value, an auth state. Each watch records an edge in the graph. When a source changes, the container marks its dependants dirty and rebuilds them lazily, and widgets that watch the result rebuild with them. When the last listener of an auto-dispose provider goes away, its state is dropped and its dispose callbacks run.

In that picture, provider types decide what a node holds, Ref draws the edges, modifiers decide when a node is created, keyed and freed, AsyncValue is what async nodes carry to the widget, and overrides replace a node before anything reads it. Codegen only writes the declarations; the runtime graph it produces is the same.

The pieces meet in a few lines — a repository at the edge, a notifier that depends on it, and a test that swaps the edge:

dart

final repoProvider = Provider<TodoRepo>((ref) => HttpTodoRepo());

class Todos extends AsyncNotifier<List<Todo>> {
  @override
  Future<List<Todo>> build() => ref.watch(repoProvider).fetchAll();
}
final todosProvider = AsyncNotifierProvider<Todos, List<Todo>>(Todos.new);

// in a test
final container = ProviderContainer.test(
  overrides: [repoProvider.overrideWithValue(FakeTodoRepo())],
);

Nothing in Todos knows about the fake. That is the property interviewers look for: the dependency is declared once, resolved by the container, and replaceable wherever the graph is built.

Start from the root. `ProviderScope` wraps the app and owns one container. When a consumer widget calls `ref.watch` on a provider for the first time, the container runs that provider's build, and the build may itself watch further providers — a repository, a settings value, an auth state. Each watch records an edge in the graph. When a source changes, the container marks its dependants dirty and rebuilds them lazily, and widgets that watch the result rebuild with them. When the last listener of an auto-dispose provider goes away, its state is dropped and its dispose callbacks run. In that picture, provider types decide what a node holds, `Ref` draws the edges, modifiers decide when a node is created, keyed and freed, `AsyncValue` is what async nodes carry to the widget, and overrides replace a node before anything reads it. Codegen only writes the declarations; the runtime graph it produces is the same. The pieces meet in a few lines — a repository at the edge, a notifier that depends on it, and a test that swaps the edge: ```dart final repoProvider = Provider<TodoRepo>((ref) => HttpTodoRepo()); class Todos extends AsyncNotifier<List<Todo>> { @override Future<List<Todo>> build() => ref.watch(repoProvider).fetchAll(); } final todosProvider = AsyncNotifierProvider<Todos, List<Todo>>(Todos.new); // in a test final container = ProviderContainer.test( overrides: [repoProvider.overrideWithValue(FakeTodoRepo())], ); ``` Nothing in `Todos` knows about the fake. That is the property interviewers look for: the dependency is declared once, resolved by the container, and replaceable wherever the graph is built.

Declared Provider Types →
Start with the kinds of provider and the job each fits; every other section assumes you can pick one.
Ref Watch, Read & Listen →
How widgets and providers consume state: watch, read and listen, and where each one belongs.
AsyncValue States →
Most real providers load data, so learn how loading, data and error states reach the screen.
Auto-Dispose & Families →
Lifetime and keying: auto-dispose, keep-alive caches and families, where leaks and surprise refetches come from.
Overrides & Containers →
Overrides and containers show why the provider graph makes Riverpod code testable without a widget tree.
Annotation Codegen →
The @riverpod syntax generates what the earlier sections taught by hand; learn it once the runtime model is clear.

Calling ref.read inside a build method to avoid rebuilds: the widget then shows stale state, because read never subscribes.
Doing setup in a notifier's constructor instead of build, where ref and state are not yet available.
Passing a freshly created list or object as a family argument, so every call misses the cache and builds new state.
Being surprised by a refetch after navigating back: auto-dispose dropped the state when the screen's last listener went away.
Rendering only the data case of an AsyncValue, or blanking the screen during a refresh that still holds the previous data.
Overriding a provider in a nested ProviderScope without declaring dependencies, so providers that watch it never see the override.
Answering with Riverpod 2 idioms such as StateNotifierProvider without saying Riverpod 3 moved them to the legacy import.

This guide assumes Riverpod 3, where the answers below are written. Many codebases in interviews are still on Riverpod 2, so it helps to know what moved:

Riverpod 2 introduced Notifier and AsyncNotifier and the @riverpod code generator, and made them the recommended way to hold mutable state.
Riverpod 3 keeps StateProvider, StateNotifierProvider and ChangeNotifierProvider only as legacy APIs behind a separate import, and expects new code to use notifiers.
Riverpod 3 added behaviour you may be asked to explain in an incident story: providers that fail while building are retried automatically, and listeners of widgets that are not visible are paused instead of notified.
Riverpod 3 also shipped experimental APIs, including mutations, which let the UI show whether a save or delete is still running. Treat anything marked experimental as subject to change and say so in an answer.

Later 3.x releases changed tooling and testing details, such as how riverpod_lint is enabled and how a notifier family is overridden. When an answer depends on one of those, name the minor version.

This guide assumes **Riverpod 3**, where the answers below are written. Many codebases in interviews are still on Riverpod 2, so it helps to know what moved: - **Riverpod 2** introduced `Notifier` and `AsyncNotifier` and the `@riverpod` code generator, and made them the recommended way to hold mutable state. - **Riverpod 3** keeps `StateProvider`, `StateNotifierProvider` and `ChangeNotifierProvider` only as legacy APIs behind a separate import, and expects new code to use notifiers. - **Riverpod 3** added behaviour you may be asked to explain in an incident story: providers that fail while building are retried automatically, and listeners of widgets that are not visible are paused instead of notified. - **Riverpod 3** also shipped experimental APIs, including mutations, which let the UI show whether a save or delete is still running. Treat anything marked experimental as subject to change and say so in an answer. Later 3.x releases changed tooling and testing details, such as how `riverpod_lint` is enabled and how a notifier family is overridden. When an answer depends on one of those, name the minor version.

Riverpod is usually weighed against three neighbours. Provider, from the same author, wraps InheritedWidget and looks providers up through BuildContext; Riverpod exists to remove that coupling. Bloc models state as streams of events and states with explicit classes for each, which suits teams that want a strict, ceremony-heavy pattern. Plain setState and InheritedWidget remain the right answer for state local to one widget. A strong answer names the trade: Riverpod gives dependency injection and caching in one tool, but you pay for it with a dependency graph you have to understand.

Around it sit the packages it is commonly used with. flutter_riverpod is the Flutter binding and hooks_riverpod adds flutter_hooks support. riverpod_generator and riverpod_lint form the codegen and analysis side, and projects that already run build_runner for freezed or json_serializable often adopt the generator alongside them.

Riverpod is usually weighed against three neighbours. **Provider**, from the same author, wraps `InheritedWidget` and looks providers up through `BuildContext`; Riverpod exists to remove that coupling. **Bloc** models state as streams of events and states with explicit classes for each, which suits teams that want a strict, ceremony-heavy pattern. Plain `setState` and `InheritedWidget` remain the right answer for state local to one widget. A strong answer names the trade: Riverpod gives dependency injection and caching in one tool, but you pay for it with a dependency graph you have to understand. Around it sit the packages it is commonly used with. `flutter_riverpod` is the Flutter binding and `hooks_riverpod` adds `flutter_hooks` support. `riverpod_generator` and `riverpod_lint` form the codegen and analysis side, and projects that already run `build_runner` for `freezed` or `json_serializable` often adopt the generator alongside them.

explore

Flutterskillanchors this topic

report an issue with this guide →

questions

page 1 of 2

In Riverpod 3, what is AsyncValue, and how do you render its loading, data and error states in a Flutter widget?

juniormust knowfreq 64%

answer

sealed, three subclasses
switch needs no default
AsyncData(:final value)
when with three callbacks
value is nullable, not throwing

basics

~10 s

AsyncValue is Riverpod's sealed result type for async providers: AsyncData, AsyncLoading or AsyncError. A widget watches the provider and switches over the AsyncValue - exhaustively, with no default - or calls when(data:, error:, loading:).

solid answer

~40 s

Watching a FutureProvider, StreamProvider or AsyncNotifierProvider returns an AsyncValue<T>, not a T. AsyncValue is a sealed class with three concrete subclasses - AsyncData, AsyncLoading and AsyncError - so a Dart 3 switch expression over it is exhaustive without a default: AsyncData(:final value) => FeedList(value), AsyncError(:final error) => ErrorView(error), AsyncLoading() => spinner. The older callback style, feed.when(data: ..., error: ..., loading: ...), still works. For quick checks there are value (nullable), hasValue, hasError and isLoading. In Riverpod 3, value never throws: it returns the data, or the previous data during loading or error, or null - the old throwing value was removed and valueOrNull renamed to value. You never write try/catch or an isLoading flag yourself.

Watching a `FutureProvider`, `StreamProvider` or `AsyncNotifierProvider` returns an `AsyncValue<T>`, not a `T`. `AsyncValue` is a **sealed** class with three concrete subclasses - `AsyncData`, `AsyncLoading` and `AsyncError` - so a Dart 3 `switch` expression over it is exhaustive without a default: `AsyncData(:final value) => FeedList(value)`, `AsyncError(:final error) => ErrorView(error)`, `AsyncLoading() => spinner`. The older callback style, `feed.when(data: ..., error: ..., loading: ...)`, still works. For quick checks there are `value` (nullable), `hasValue`, `hasError` and `isLoading`. In Riverpod 3, `value` never throws: it returns the data, or the previous data during loading or error, or `null` - the old throwing `value` was removed and `valueOrNull` renamed to `value`. You never write `try`/`catch` or an `isLoading` flag yourself.

code

dart · 24 lines

dart

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

final newsFeedProvider = FutureProvider<List<Article>>((ref) async {
  return ref.watch(newsApiProvider).fetchHeadlines();
});

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final feed = ref.watch(newsFeedProvider);
    return switch (feed) {
      AsyncData(:final value) => ListView(
          children: [
            for (final article in value) ListTile(title: Text(article.title)),
          ],
        ),
      AsyncError(:final error) => Center(child: Text('Could not load news: $error')),
      AsyncLoading() => const Center(child: CircularProgressIndicator()),
    };
  }
}

go deeper

for a junior

Recall the three states and write the switch with AsyncData, AsyncError and AsyncLoading branches. Know that watching an async provider gives an AsyncValue.

for a middle

Explain why sealing makes the switch exhaustive, compare switch with when, and describe what value, hasValue and isLoading report.

for a senior

Standardise how screens render async state, including error presentation and logging from the stack trace, and remove FutureBuilder duplication.

for a principal

Decide a house style - patterns versus when, shared loading and error widgets - so async screens look and behave consistently across teams.

What AsyncValue is

An async provider - FutureProvider, StreamProvider, AsyncNotifierProvider, StreamNotifierProvider - does not hand widgets a Future or Stream. It exposes an AsyncValue<T>: a snapshot of the operation's state that the widget can render synchronously on every build. For a news app, ref.watch(newsFeedProvider) returns AsyncValue<List<Article>>.

AsyncValue is a sealed class. Its concrete subclasses are:

Subclass	Meaning	Key fields
`AsyncData<T>`	a value is available	`value` (non-null type `T`)
`AsyncLoading<T>`	the operation is in progress	`progress` (optional, 0 to 1)
`AsyncError<T>`	the operation failed	`error`, `stackTrace`

Because the hierarchy is sealed, the Dart analyzer knows these are the only possibilities.

Rendering with switch

The recommended Riverpod 3 style is a Dart 3 switch expression:

dart

final feed = ref.watch(newsFeedProvider);
return switch (feed) {
  AsyncData(:final value) => ArticleList(articles: value),
  AsyncError(:final error) => FeedError(message: '$error'),
  AsyncLoading() => const Center(child: CircularProgressIndicator()),
};

No default branch is needed; forgetting a case is a compile error.
:final value destructures the field into a local.
The AsyncError branch can also bind :final stackTrace for logging.

The Riverpod tutorial also shows a property-pattern style - AsyncValue(:final value?), then AsyncValue(error: != null), then AsyncValue() - and warns that with that style the order matters: check value first, error second, loading last.

Rendering with when

Before patterns existed, the idiom was a method with three required callbacks:

dart

return feed.when(
  data: (articles) => ArticleList(articles: articles),
  error: (error, stackTrace) => FeedError(message: '$error'),
  loading: () => const Center(child: CircularProgressIndicator()),
);

when is still in Riverpod 3 and adds flags for multi-state situations such as refreshing. Related helpers:

maybeWhen / whenOrNull - handle only some cases.
whenData(cb) - transform the data and keep loading and error as they are, returning a new AsyncValue.

Quick accessors

value - the data, or the previous data while loading or after an error, or null if there has never been any.
hasValue, hasError, isLoading - booleans that can be true at the same time.
error, stackTrace - nullable on the base type.
requireValue - the data, or throws; for code that is sure data exists.

What changed in Riverpod 3

AsyncValue became sealed, enabling exhaustive switches.
valueOrNull was renamed to value; the old value, which rethrew errors, was removed.
AsyncLoading gained an optional progress.

Common mistakes

Treating ref.watch(newsFeedProvider) as the list itself and calling .length on it.
Writing a FutureBuilder around a provider's future, which re-creates what AsyncValue already gives you.
Adding a default case, which hides a missing branch from the compiler.

Choosing between switch and when

Both styles produce the same screen for the simple case, and interviewers mostly want to hear that you know why the pattern style is now preferred:

The switch is plain Dart: the compiler checks exhaustiveness, and each branch can destructure exactly the fields it needs.
when hides multi-state details behind flags, which is convenient but makes it easier to forget what a refresh or an error after data looks like.
A switch on the concrete subclasses and a switch on properties such as AsyncValue(:final value?) behave differently when old data is carried along; pick one style per codebase and document it.

## What AsyncValue is An **async provider** - `FutureProvider`, `StreamProvider`, `AsyncNotifierProvider`, `StreamNotifierProvider` - does not hand widgets a `Future` or `Stream`. It exposes an `AsyncValue<T>`: a snapshot of the operation's state that the widget can render synchronously on every build. For a news app, `ref.watch(newsFeedProvider)` returns `AsyncValue<List<Article>>`. `AsyncValue` is a **sealed class**. Its concrete subclasses are: | Subclass | Meaning | Key fields | |---|---|---| | `AsyncData<T>` | a value is available | `value` (non-null type `T`) | | `AsyncLoading<T>` | the operation is in progress | `progress` (optional, 0 to 1) | | `AsyncError<T>` | the operation failed | `error`, `stackTrace` | Because the hierarchy is sealed, the Dart analyzer knows these are the only possibilities. ## Rendering with switch The recommended Riverpod 3 style is a Dart 3 `switch` expression: ```dart final feed = ref.watch(newsFeedProvider); return switch (feed) { AsyncData(:final value) => ArticleList(articles: value), AsyncError(:final error) => FeedError(message: '$error'), AsyncLoading() => const Center(child: CircularProgressIndicator()), }; ``` - No `default` branch is needed; forgetting a case is a compile error. - `:final value` destructures the field into a local. - The `AsyncError` branch can also bind `:final stackTrace` for logging. The Riverpod tutorial also shows a property-pattern style - `AsyncValue(:final value?)`, then `AsyncValue(error: != null)`, then `AsyncValue()` - and warns that with that style the order matters: check value first, error second, loading last. ## Rendering with when Before patterns existed, the idiom was a method with three required callbacks: ```dart return feed.when( data: (articles) => ArticleList(articles: articles), error: (error, stackTrace) => FeedError(message: '$error'), loading: () => const Center(child: CircularProgressIndicator()), ); ``` `when` is still in Riverpod 3 and adds flags for multi-state situations such as refreshing. Related helpers: - `maybeWhen` / `whenOrNull` - handle only some cases. - `whenData(cb)` - transform the data and keep loading and error as they are, returning a new `AsyncValue`. ## Quick accessors 1. `value` - the data, or the previous data while loading or after an error, or `null` if there has never been any. 2. `hasValue`, `hasError`, `isLoading` - booleans that can be true at the same time. 3. `error`, `stackTrace` - nullable on the base type. 4. `requireValue` - the data, or throws; for code that is sure data exists. ## What changed in Riverpod 3 - `AsyncValue` became sealed, enabling exhaustive switches. - `valueOrNull` was renamed to `value`; the old `value`, which rethrew errors, was removed. - `AsyncLoading` gained an optional `progress`. ## Common mistakes - Treating `ref.watch(newsFeedProvider)` as the list itself and calling `.length` on it. - Writing a `FutureBuilder` around a provider's future, which re-creates what `AsyncValue` already gives you. - Adding a `default` case, which hides a missing branch from the compiler. ## Choosing between switch and when Both styles produce the same screen for the simple case, and interviewers mostly want to hear that you know why the pattern style is now preferred: - The `switch` is plain Dart: the compiler checks exhaustiveness, and each branch can destructure exactly the fields it needs. - `when` hides multi-state details behind flags, which is convenient but makes it easier to forget what a refresh or an error after data looks like. - A `switch` on the concrete subclasses and a `switch` on properties such as `AsyncValue(:final value?)` behave differently when old data is carried along; pick one style per codebase and document it.

How is AsyncValue different from Flutter's AsyncSnapshot?
Both describe an async result, but `AsyncValue` is produced and cached by the provider rather than by a builder widget, so every widget watching the provider shares one fetch. It is sealed, so switches over it are exhaustive, and it can carry previous data together with a loading or error state, which is what makes stale-while-refreshing screens simple.
What does whenData do on an AsyncValue<List<Article>>?
It maps only the data, for example `feed.whenData((a) => a.length)` gives an `AsyncValue<int>`. Loading and error pass through unchanged, and if the callback throws, the result becomes an `AsyncError`. It is handy for deriving a value while keeping the three-state shape for the widget.

saying these in an interview costs you the question

ref.watch on a FutureProvider returns the Future to await in build
A switch over AsyncValue needs a default branch to compile
In Riverpod 3 value throws when the provider is in error
You must wrap provider reads in try/catch to handle failures
AsyncValue is an enum with three constants

§guide

overview

§primer

▾core ideas~2 min

Providers are declarations, not widgets

Dependencies form a graph

Lifetime is explicit

Async is a value, not a callback

Mutation goes through notifiers

Tests swap the graph, not the code

▾vocabulary12 terms

▾how it fits~1 min

▾where to start6 steps

▾common pitfalls7

▾versions4

▾ecosystem~50 s

§explore

▾sections6 · 31 questions

▾roadmaps that cover this1

§questions

In Riverpod 3, what is AsyncValue, and how do you render its loading, data and error states in a Flutter widget?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What AsyncValue is

Rendering with switch

Rendering with when

Quick accessors

What changed in Riverpod 3

Common mistakes

Choosing between switch and when

▾common follow-ups2 questions

▾red flags5 flags

In Riverpod 3 with riverpod_generator, what does annotating a function versus a Notifier class with @riverpod generate, and how is it named?

basics

In Riverpod 3, what does autoDispose do, and why does a product-detail screen refetch after you leave and reopen it?

basics

In Riverpod 3, which provider type fits a computed value, a one-off async load, a live stream, and state the UI changes?

basics

In Riverpod 3, what is the difference between ref.watch, ref.read and ref.listen, and where does each one belong?

basics

In Riverpod 3, how do you swap a quiz app's repository provider for a fake in a Flutter widget test?

basics

In Riverpod 3, when does riverpod_generator's @riverpod syntax pay off, and when do hand-written providers fit better?

basics

In Riverpod 3, how does a Notifier's build() method work, and why must initialization live in build rather than the constructor?

basics

In Riverpod 3 unit tests, why use ProviderContainer.test and container.listen rather than a shared container and container.read?

basics

In flutter_riverpod 3, how do ConsumerWidget, ConsumerStatefulWidget and Consumer each give you a WidgetRef, and when do you pick each?

basics

In a Riverpod 3 AsyncNotifier, what does AsyncValue.guard do, and what does state hold if a guarded news-feed refresh fails?

basics

In Riverpod 3, what does a news feed's AsyncValue contain while it refreshes, and how do isRefreshing and skipLoadingOnRefresh keep old articles visible?

basics

With riverpod_generator, how do extra parameters on a @riverpod function or a Notifier's build method turn a provider into a family?

basics

With riverpod_generator, why is a @riverpod provider disposed once nothing listens to it, and what does @Riverpod(keepAlive: true) change?

basics

In Riverpod 3, how does .family give each product id its own state, and why must the argument have a consistent == and hashCode?

basics

In Riverpod 3, how would you cache an autoDispose product-detail provider for five minutes while never caching a failed request?

basics

In Riverpod 3, when do you choose AsyncNotifierProvider over FutureProvider, and how do an AsyncNotifier's build, state, future and update work?

basics

With Riverpod 3, how does StreamProvider expose a live unread-notifications count, and what does a widget get from ref.watch on it?

basics

In Riverpod 3, what is the difference between ref.invalidate and ref.refresh, and when would you pass asReload: true?

basics

In Riverpod 3, how does provider.select narrow a widget's rebuilds, and what does it not save you from?

basics

In Riverpod 3, how do overrideWith, overrideWithValue and overrideWithBuild differ when you override a provider?

basics

In Riverpod 3, how does AsyncValue.requireValue let a provider combine two async providers without await, and when is it dangerous inside a widget?

basics

Migrating a fitness app's hand-written Riverpod 3 providers to @riverpod, what behaviour changes and what breaks at the call sites?

guide

primer

explore

questions

answer

go deeper