riverpod-faq-and-practices

Riverpod's ref.refresh and ref.invalidate differ in execution: refresh immediately recreates the provider state and returns the new value, while invalidate marks the provider as dirty for lazy recreation on next access.

To safely manage providers and avoid memory leaks, use ref.watch with top-level static providers. Avoid creating providers dynamically inside class instances or widgets to prevent initialization errors and state inconsistencies.

Avoiding side effects in Riverpod providers ensures reliable state management. Side effects during build can cause unexpected rebuilds and state mutations, breaking the safe, effective consistency required for maintainable Flutter architecture.

Yes, flutter_hooks can be used with Riverpod for managing ephemeral state. Separating Ref and WidgetRef allows developers to safely handle temporary UI state while maintaining consistent static provider references.

Creating providers inside class instances limits Riverpod state safety by causing dynamic provider generation. This leads to memory leaks and state loss, breaking the static referencing pattern required for consistent Flutter state management.