Declarative programming

Write business logic in a manner similar to Stateless widgets.
Have your network requests to automatically recompute when necessary and make your logic easily reusable/composable/maintainable.

Easily implement common UI patterns

Using Riverpod, common yet complex UI patterns such as "pull to refresh"/ "search as we type"/etc... are only a few lines of code away.

Tooling ready

Riverpod enhances the compiler by having common mistakes be a compilation-error. It also provides custom lint rules and refactoring options. It even has a command line for generating docs.

Features

✅ Declarative programming
✅ Native network requests support
✅ Automatic loading/error handling
✅ Compile safety
✅ Type-safe query parameters
✅ Test ready
✅ Work in plain Dart (servers/CLI/...)
✅ Easily combinable states
✅ Built-in support for pull-to-refresh
✅ Custom lint rules
✅ Built-in refactorings
✅ Hot-reload support
✅ Logging
✅ Websocket support
✅ Documentation generator

Declare shared state from anywhere

No need to jump between your main.dart and your UI files anymore.
Place the code of your shared state where it belongs, be it in a separate package or right next to the Widget that needs it, without losing testability.

// A shared state that can be accessed by multiple widgets at the same time.
@riverpod
class Count extends _$Count {
  @override
  int build() => 0;

  void increment() => state++;
}

// Consumes the shared state and rebuild when it changes
class Title extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(countProvider);
    return Text('$count');
  }
}

Recompute states/rebuild UI only when needed

We no longer have to sort/filter lists inside the build method or have to resort to advanced cache mechanism.

With Provider and "families", sort your lists or do HTTP requests only when you truly need it.

@riverpod
List<Todo> filteredTodos(FilteredTodosRef ref) {
  // Providers can consumer other providers using the "ref" object.
  // With ref.watch, providers will automatically update if the watched values changes.
  final List<Todo> todos = ref.watch(todosProvider);
  final Filter filter = ref.watch(filterProvider);

  switch (filter) {
    case Filter.all:
      return todos;
    case Filter.completed:
      return todos.where((todo) => todo.completed).toList();
    case Filter.uncompleted:
      return todos.where((todo) => !todo.completed).toList();
  }
}

Simplify day-to-day work with refactors

Riverpod offers various refactors, such as "Wrap widget in a Consumer" and many more. See the list of refactorings.

Keep your code maintainable with lint rules

New lint-rules specific to Riverpod are implemented and more are continuously added. This ensures your code stays in the best conditions. See the list of lint rules.

Safely read providers

Reading a provider will never result in a bad state. If you can write the code needed to read a provider, you will obtain a valid value.

This even applies to asynchronously loaded values. As opposed to with provider, Riverpod allows cleanly handling loading/error cases.

@riverpod
Future<Configuration> configurations(ConfigurationsRef ref) async {
  final uri = Uri.parse('configs.json');
  final rawJson = await File.fromUri(uri).readAsString();

  return Configuration.fromJson(json.decode(rawJson));
}

class Example extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final configs = ref.watch(configurationsProvider);

    // Use pattern matching to safely handle loading/error states
    return switch (configs) {
      AsyncData(:final value) => Text('data: ${value.host}'),
      AsyncError(:final error) => Text('error: $error'),
      _ => const CircularProgressIndicator(),
    };
  }
}

Inspect your state in the devtool

Using Riverpod, your state is visible out of the box inside Flutter's devtool.
Furthermore, a full-blown state-inspector is in progress.