riverpod-codegen-and-hooks

Riverpod — Code generation and hooks

Code generation

Code generation is optional in Riverpod. It changes the syntax for defining providers: you write an annotated function or class and the generator produces the provider. Use it if you already use code generation (e.g. Freezed, json_serializable); otherwise the extra build step may not be worth it. See riverpod-getting-started for setup (build_runner, riverpod_generator).

Benefits

• Clearer syntax: no manual provider type (Provider vs FutureProvider etc.); Riverpod infers it.
• Parameters: any parameters (named, optional, defaults) instead of a single family parameter.
• Stateful hot-reload for Riverpod code.
• Better debugging via generated metadata.

Syntax

Functional provider (sync):

@riverpod
String example(Ref ref) {
  return 'foo';
}

Class-based provider (sync, with methods for side effects):

@riverpod
class Example extends _$Example {
  @override
  String build() => 'foo';
  // Add methods to mutate state
}

Async: Use Future/FutureOr/Stream; async functions get AsyncValue and loading/error handling automatically. Auto-dispose: On by default with codegen. Disable with @Riverpod(keepAlive: true).

@riverpod
String example1(Ref ref) => 'foo';

@Riverpod(keepAlive: true)
String example2(Ref ref) => 'foo';

Parameters: Add parameters to the function (consistent == required):

@riverpod
Future<User> fetchUser(Ref ref, {required int userId}) async {
  final json = await http.get('api/user/$userId');
  return User.fromJson(json);
}

Manual equivalent would be FutureProvider.autoDispose.family<User, int>(...). See riverpod-providers and riverpod-family for concepts.

---

Hooks

Hooks come from [flutter_hooks] (separate from Riverpod). They are for local widget state (e.g. TextEditingController, AnimationController) and can replace StatefulWidget or builder nesting. Use them only if you want hooks; they are not required for Riverpod. Newcomers should avoid hooks at first.