Frequently Asked Questions

No, code generation is optional. You can use Riverpod with manual provider definitions. However, code generation provides several benefits:

• Automatic disposal and lifecycle management
• Type-safe provider references
• Reduced boilerplate code
• Better IDE support and refactoring

Yes. You can use both generated providers with @riverpod and manual providers in the same project. This allows gradual migration or mixing approaches based on your needs.

For development:

dart run build_runner watch

For one-time builds:

dart run build_runner build

To clean generated files:

dart run build_runner clean

Check these common issues:

• Make sure you have the part directive in your file
• Verify riverpod_generator is in dev_dependencies
• Check for syntax errors in your provider code
• Run flutter clean and try again
• Ensure file names match the part directive

Make sure your part directive matches the file name exactly. For a file named counter.dart, use:

part 'counter.g.dart';

The generated file will be counter.g.dart and should contain:

part of 'counter.dart';

Limited customization is available through annotations. You can:

• Use @Riverpod(keepAlive: true) to prevent disposal
• Add dependencies with the dependencies parameter
• Control caching behavior with provider modifiers

Follow these best practices:

• Use select to watch only specific parts of state
• Implement efficient == operators for custom state classes
• Use keepAlive for expensive computations
• Avoid creating providers inside build methods
• Use family providers for parameterized data

Use family providers when you need multiple instances of the same provider with different parameters:

@riverpod
Future<User> user(UserRef ref, int userId) async {
  return await userRepository.getUser(userId);
}

// Usage: ref.watch(userProvider(123))

Generated providers handle disposal automatically. For manual control:

@Riverpod(keepAlive: false) // Auto-dispose (default)
@Riverpod(keepAlive: true)  // Keep alive

// Or use ref.keepAlive() conditionally:
@riverpod
String expensiveComputation(ExpensiveComputationRef ref) {
  ref.keepAlive(); // Prevent disposal
  return performExpensiveOperation();
}

Use ProviderContainer for unit testing:

test('counter increments correctly', () {
  final container = ProviderContainer();
  
  expect(container.read(counterProvider), 0);
  
  container.read(counterProvider.notifier).increment();
  
  expect(container.read(counterProvider), 1);
});

Yes, use overrides:

final container = ProviderContainer(
  overrides: [
    userRepositoryProvider.overrideWithValue(mockUserRepository),
  ],
);

Follow these migration steps:

1. 1Replace ChangeNotifierProvider with NotifierProvider
2. 2Update Consumer widgets to ConsumerWidget
3. 3Change context.read() to ref.read()
4. 4Replace context.watch() with ref.watch()
5. 5Gradually adopt code generation for new providers

Yes, but they use different widget trees. You will need separate ProviderScope and MultiProvider widgets until migration is complete.

We provide snippets and extensions for:

• Visual Studio Code (Riverpod Snippets extension)
• IntelliJ IDEA / Android Studio (Live Templates)
• Vim/Neovim (with LSP support)

Make sure to:

• Run build_runner to generate provider files
• Restart your IDE after generating code
• Use dart analyze to check for issues
• Enable Dart/Flutter language server features