为何FutureProvider无dispose回调？异步对象销毁及与FutureProvider.value差异

Great question! Managing async initialization and cleanup with Riverpod can feel a bit counterintuitive at first, so let's break this down clearly.

1. How to Dispose LocalStorageManager with FutureProvider #

You're right that FutureProvider doesn't include a direct dispose callback like the basic Provider does. The solution here is to use a provider type that supports lifecycle hooks for cleanup, while still handling your async initialization. Here are two solid approaches depending on your Riverpod version:

Option 1: Use AsyncNotifierProvider (Riverpod 2.x+) #

This is the recommended modern approach. AsyncNotifierProvider combines async initialization with built-in support for cleanup via the dispose method:

final localStorageManagerProvider = AsyncNotifierProvider<LocalStorageManagerNotifier, LocalStorageManager>(
  LocalStorageManagerNotifier.new,
);

class LocalStorageManagerNotifier extends AsyncNotifier<LocalStorageManager> {
  @override
  Future<LocalStorageManager> build() async {
    // Initialize your manager asynchronously
    final manager = LocalStorageManager();
    await manager.initialize();
    return manager;
  }

  @override
  void dispose() {
    // Clean up when the provider is destroyed
    state.whenData((manager) => manager.dispose());
    super.dispose();
  }
}

When the provider is no longer used (e.g., the widget that listens to it is disposed), the dispose method will trigger, letting you call your manager's dispose() method safely.

Option 2: Combine StateProvider + FutureProvider (Riverpod 1.x or 2.x) #

If you're working with an older Riverpod version or prefer a more explicit split between initialization and state holding, you can pair a StateProvider (which supports autoDispose cleanup) with a FutureProvider for async setup:

// Hold the initialized manager instance with cleanup support
final localStorageManagerProvider = StateProvider<LocalStorageManager?>((ref) => null)
  ..autoDispose((ref, manager) {
    manager?.dispose(); // Clean up when the provider is disposed
  });

// Handle async initialization
final localStorageInitProvider = FutureProvider<void>((ref) async {
  final manager = LocalStorageManager();
  await manager.initialize();
  // Store the initialized manager in the StateProvider
  ref.read(localStorageManagerProvider.notifier).state = manager;
});

Here, the StateProvider takes care of cleanup via autoDispose, while the FutureProvider handles the async initialization step.

2. Difference Between FutureProvider and FutureProvider.value (Without Lifecycle Management) #

When you're not actively managing lifecycle (e.g., not using autoDispose), here's how these two variants differ:

• FutureProvider(create: ...):

  • The create function runs only when the provider is first listened to, and its result is cached by default.
  • If the future fails, subsequent listeners will trigger a re-run of the create function to retry initialization.
  • It reacts to dependencies: if you use ref.watch inside create, the provider will re-run the create function when those dependencies change.

• FutureProvider.value(value: existingFuture):

  • You pass a pre-created Future directly, so no initialization logic runs inside the provider itself.
  • The provider doesn't cache the future's state independently—it just forwards the state of the Future you passed in.
  • It doesn't react to dependencies; even if the source of your existingFuture changes, the provider won't update unless you explicitly pass a new Future to value.
  • The lifecycle of the Future is controlled entirely by your code, not the provider.

In short: use FutureProvider(create: ...) when you need the provider to handle creating and caching the async work, and FutureProvider.value when you already have a Future instance and just want to expose its state to your widgets.

内容的提问来源于stack exchange，提问作者Frank Treacy