Flutter Riverpod: Why Does My State Reset?

1. "I Went Back, and Data Was Gone?"

I was working on a Product Detail Page for an e-commerce app. The user selected options (Color, Size), clicked 'Back' to browse other items, and returned. All selected options were Reset to Default.

"What? Isn't this Global State? Why did data vanish?"

The culprit was my mindless use of .autoDispose.

---

2. The Principle: "If No One Watches, I Kill It."

Riverpod's superpower is autoDispose.

final productProvider = StateProvider.autoDispose<Product>((ref) => ...);

This modifier makes the Provider smart yet ruthless. "If there are ZERO widgets watching me, I immediately delete myself from memory."

1. Enter DetailPage. -> Subscriber count: 1 (Created).
2. User clicks Back (pop). -> DetailPage destroyed.
3. Subscriber count: 0. -> Provider Disposed.
4. User enters again. -> Provider Re-created (Reset to Initial).

This is excellent for preventing memory leaks, but poison for "State Persistence".

---

3. Solution 1: Remove autoDispose (Persistence)

If data should persist while the app is running (e.g., Cart, User Profile), just remove autoDispose.

final cartProvider = StateProvider<List<Item>>((ref) => []);

Now the state lives until the app terminates. But if you do this for everything, your app's memory usage will explode over time.

---

4. Solution 2: ref.keepAlive() (Timeout Caching)

"I want to keep it for a while, but not forever." For example, keeping product details while the user browses back and forth effectively, but dropping it if they leave for 5 minutes.

Use ref.keepAlive().

final detailProvider = FutureProvider.autoDispose.family<Detail, int>((ref, id) async {
  // 1. Get a keepAlive link
  final link = ref.keepAlive();

  // 2. Set Timer (e.g., Dispose after 3 mins)
  final timer = Timer(const Duration(minutes: 3), () {
    link.close(); // 3. Cut the link, allowing Dispose
  });

  // 4. Cancel timer if re-subscribed
  ref.onDispose(() => timer.cancel());

  return fetchDetail(id);
});

This implements a Smart Cache strategy: "Cache for at least 3 mins, then auto-release."

---

5. Force Refresh (invalidate vs refresh)

Sometimes you WANT to reset a provider manually. Like "Pull to Refresh".

• ref.invalidate(provider): Marks state as "Stale". It re-fetches ONLY when someone tries to read/watch it next time. (Lazy)
• ref.refresh(provider): Immediately re-executes the logic and returns value. (Eager)

Use invalidate usually. Use refresh if you need to await the result right now.

---

---

6. Deep Dive: Riverpod Generator Syntax (@Riverpod)

Modern Riverpod uses Code Generation to simplify keepAlive. By default, all generated providers are autoDispose.

@Riverpod(keepAlive: true)
class UserCarts extends _$UserCarts {
  // ... Persists forever (Singleton)
}

@riverpod
Future<Product> productDetail(ProductDetailRef ref, int id) {
  // autoDispose by default
  ref.keepAlive(); // Keep it alive conditionally!
  return fetch(id);
}

Using the Generator eliminates the confusion between Provider, FutureProvider, StateProvider. Just write a function, annotate @riverpod, and let the compiler decide.

7. Deep Dive: Search Autocomplete (Debouncing)

Calling API on every keystroke kills your server. Use ref.onDispose to implement Debouncing.

@riverpod
Future<List<String>> search(SearchRef ref, String query) async {
  final cancelToken = CancelToken();
  
  // Cancel previous request if query changes
  ref.onDispose(() => cancelToken.cancel());

  // Wait 500ms
  await Future.delayed(const Duration(milliseconds: 500));
  
  // Check explicitly
  if (cancelToken.isCancelled) throw AbortedException();

  return fetchResults(query, cancelToken);
}

If user types "apple", requests for a, ap, app, appl get cancelled. Only apple hits the network. Pure magic without RxDart.

9. Deep Dive: StateNotifier vs Notifier (The Shift)

Are you still using StateNotifier? Riverpod 2.0 recommends moving to Notifier (Class-based providers). Why? Because keepAlive, ref, and lifecycle hooks are first-class citizens in Notifier.

Legacy (StateNotifier): You don't have access to ref inside the class easy unless passed in constructor. Handling onDispose is awkward.

Modern (Notifier):

@riverpod
class Counter extends _$Counter {
  @override
  int build() {
    // You can use ref here!
    ref.onDispose(() => print("I am dying"));
    return 0;
  }

  void increment() => state++;
}

The code is cleaner, and logic regarding "Lifecycle" (creation/destruction) lives right inside the build() method.

10. Case Study: Unit Testing Lifecycle

How to verify if your provider resets correctly without manually tapping the UI? Write a Unit Test.

test('State resets on dispose', () {
  final container = ProviderContainer();
  // Subscribe to keep it alive
  final sub = container.listen(counterProvider, (_, __) {});

  // 1. Change State
  container.read(counterProvider.notifier).increment();
  expect(container.read(counterProvider), 1);

  // 2. Unsubscribe (Trigger Dispose)
  sub.close();

  // 3. Re-read (Should be reset)
  expect(container.read(counterProvider), 0);
});

Manually controlling ProviderContainer is the best way to master Riverpod's internal mechanism.

11. Refactoring Challenge: Converting to Notifier

Want cleaner code? Ditch ChangeNotifier.

Before (ChangeNotifier):

class Auth extends ChangeNotifier {
  bool isLoading = false;
  
  void login() {
    isLoading = true;
    notifyListeners(); // Manual, Error-prone
  }
}

Cons: Mutable state, manual notifications, verbose.

After (Notifier):

@riverpod
class Auth extends _$Auth {
  @override
  bool build() => false;

  void login() {
    state = true; // Auto-notifies listeners
  }
}

Pros: Immutable by default, less boilerplate, better performance.

12. Case Study: The Wizard Form Disaster

I was building a Multi-step Registration Form. Step 1 (Email) -> Step 2 (Password) -> Step 3 (Profile).

User went from Step 2 back to Step 1. Step 1 was empty. Why? Step1Page popped -> Provider had 0 listeners -> autoDispose killed it.

Fix: For Wizards, use Session Persistence (keepAlive or remove autoDispose). Only clear state when user clicks "Submit" at the very end. ref.invalidate(formProvider) is your friend.

---

---

9. Glossary

• ProviderScope: The root widget that stores all provider states.
• Dispose: Cleaning up resources (memory, listeners).
• Stale Data: Data that is cached but potentially outdated.
• KeepAlive: A mechanism to prevent auto-disposal even when there are no listeners.
• Debouncing: Delaying the processing of a function until a certain amount of time has passed since the last time it was invoked.

---

10. Summary

Riverpod state resetting is not a bug; it's a feature.

1. autoDispose cleans up. (Garbage Collection)
2. Remove it for persistence. (Global Singleton)
3. Use keepAlive() for temporary caching. (Smart Cache)
4. Use invalidate for pull-to-refresh.

Designing the Lifecycle of Data distinguishes the Senior from the Junior.