Expert knowledge in Flutter Riverpod state management (2025 best practices). Use when working with Riverpod, Flutter state management, AsyncNotifier, provider types, code generation with riverpod_generator, state synchronization, or when the user mentions data fetching, mutations, reactive state, pe

Flutter Riverpod Expert 2025 Best Practices You have expert knowledge in Flutter Riverpod state management following 2025 best practices. When the user is working with Riverpod or Flutter state management, apply these patterns and guidelines. When to Use This Skill Activate this expertise when the user mentions: Riverpod, providers, state management, or StateNotifier AsyncNotifier, FutureProvider, StreamProvider, NotifierProvider Code generation with riverpod generator or build runner Data fetching, API integration, mutations, or reactive state State synchronization, caching, autoDispose, or memory management Provider testing, dependency injection, or repository patterns Performance issues with rebuilds, provider selection, or optimization Migration from old Riverpod patterns to modern approaches Core Principles (2025) 1. Code Generation is STRONGLY RECOMMENDED Use @riverpod annotations and riverpod generator 2. AsyncNotifierProvider is PREFERRED for async state (replaces FutureProvider/StreamProvider for consistency) 3. AutoDispose by Default Codegen makes providers auto dispose automatically 4. Repository Pattern Separate data layer from state management 5. Performance First Use select() to optimize rebuilds Provider Selection Guide Quick Decision Tree Immutable/Computed Values Use Provider : Simple Synchronous State Use NotifierProvider : Async Data with Mutations (PREFERRED 2025) Use AsyncNotifierProvider : Real time Streams Only Use StreamProvider : Key Rule : Prefer AsyncNotifierProvider over FutureProvider/StreamProvider for better consistency and mutation support. Code Generation Setup Dependencies (pubspec.yaml) File Template Every provider file needs: Run Generator Performance Optimization Patterns Use ref.select() for Specific Fields ref.watch() vs ref.select() vs ref.read() vs ref.listen() ref.watch() Subscribe to changes (use in build): ref.select() Subscribe to specific property (optimize rebuilds): ref.read() One time read with NO subscription (event handlers only): ref.listen() Side effects (navigation, snackbars, logging): Avoid Watching in Loops Create Derived Providers Repository Pattern Architecture 3 Layer Architecture 1. Data Layer Repository : 2. Application Layer State Management : 3. Presentation Layer UI : Dependency Injection Family Providers (Parameterized) Family providers are automatic with code generation when you add parameters: AutoDispose and Caching Code generation makes providers auto dispose by default . Error Handling Comprehensive Error Handling UI Error Handling Testing Provider Testing Widget Testing Common Anti Patterns to AVOID Performance Pitfalls Memory Leaks Multiple Sources of Truth Not Invalidating Dependent Providers Instructions for Use When the user is working with Riverpod: 1. Always recommend code generation with @riverpod annotations 2. Prefer AsyncNotifierProvider over FutureProvider/StreamProvider for async state 3. Optimize performance by suggesting select() when watching specific fields 4. Follow repository pattern for clean architecture 5. Use proper error handling with AsyncValue.guard() and .when() 6. Remind about autoDispose and caching strategies 7. Point out anti patterns if you see them in user code 8. Provide complete, working examples with proper imports Reference For complete details and advanced patterns, refer to: /Users/pablito/EVOworkspace/flutter/CesarferPromotoresFlutter/promotores/RIVERPOD 2025 BEST PRACTICES.md

flutter-riverpod-expert