// Eagerly initialize Riverpod providers at app startup by watching them in a root Consumer; handle loading/error in the initializer, AsyncValue.requireValue. Use when a provider must be ready before the rest of the app is used. Use this skill when the user asks about eager initialization or preloading providers.
Migrate Riverpod from 2.0 to 3.0; automatic retry, paused listeners, legacy providers import, Ref simplification, FamilyNotifier removal, ProviderException, updateShouldNotify. Use when the user asks about Riverpod 3 migration, upgrading to Riverpod 3, or breaking changes in 3.0.
Enable automatic disposal of Riverpod providers when they have no listeners; keepAlive, onDispose, invalidate, ref.keepAlive. Use when preventing memory leaks, caching only while used, or cleaning up resources when a provider is no longer needed. Use this skill when the user asks about auto-dispose, keepAlive, or when to dispose Riverpod state.
Cancel or debounce Riverpod async requests with ref.onDispose; cancel when user leaves the page, debounce rapid refreshes. Use when the user asks about cancelling requests, debouncing, or cleaning up when a provider is disposed.
Use Riverpod code generation (@riverpod, riverpod_generator) and hooks (hooks_riverpod, HookConsumerWidget, flutter_hooks with Riverpod). Use when the user asks about @riverpod, code generation, riverpod_generator, when to use codegen, or using flutter_hooks with Riverpod (HookConsumerWidget, HookConsumer).
Use Riverpod Consumer, ConsumerWidget, and ConsumerStatefulWidget to read and watch providers in widgets; WidgetRef, builder ref parameter. Use when building widgets that need to access Riverpod providers, ref.watch or ref.read in the UI, or converting StatelessWidget to ConsumerWidget. Prefer this skill when the user asks how to use providers in Flutter widgets or why ConsumerWidget is required.
Use ProviderScope in Flutter and ProviderContainer in Dart for Riverpod; where provider state is stored, overrides, observers, testing with ProviderContainer.test. Use when setting up Riverpod in Flutter or pure Dart, understanding where state lives, or writing tests with a fresh container. Use this skill when the user asks about ProviderScope, ProviderContainer, or where Riverpod stores state.
| name | riverpod-eager-initialization |
| description | Eagerly initialize Riverpod providers at app startup by watching them in a root Consumer; handle loading/error in the initializer, AsyncValue.requireValue. Use when a provider must be ready before the rest of the app is used. Use this skill when the user asks about eager initialization or preloading providers. |
Providers are lazy by default: they initialize on first use. There is no built-in "eager" flag (for tree-shaking). To force early initialization, watch the provider at the root of your app so it stays alive and runs immediately.
Place a Consumer (or ConsumerWidget) directly under ProviderScope that only watches the providers you want to initialize and returns your real app as child:
void main() {
runApp(ProviderScope(child: MyApp()));
}
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return const _EagerInitialization(child: MaterialApp());
}
}
class _EagerInitialization extends ConsumerWidget {
const _EagerInitialization({required this.child});
final Widget child;
@override
Widget build(BuildContext context, WidgetRef ref) {
ref.watch(myProvider); // Eagerly initialize
return child;
}
}
Only the initializer widget rebuilds when the provider changes; child is unchanged so Flutter does not rebuild the rest of the tree unless something else is listening.
If the provider is async, handle loading/error in the initializer (e.g. show CircularProgressIndicator or error until ready, then return child). Other widgets can use AsyncValue.requireValue to read the data without pattern matching; if they run before the value is ready, it throws with a clear message.
Put the initializer in a shared widget (e.g. MyApp) so tests can reuse the same setup by using that widget.