riverpod
| Package | Kind | Provides the role | Needs | Choose with |
|---|---|---|---|---|
smf_riverpod | infrastructure | State management | nothing | -m riverpod |
riverpod manages the state of screens with Riverpod 3, through flutter_riverpod, without code generation.
What it adds to the app
The module adds flutter_riverpod: ^3.4.3 to the dependencies, and a ProviderScope around the root widget in lib/main.dart:
runApp(ProviderScope(child: const App()));
Features with state
A feature that keeps state supports Riverpod through a variant keyed by the id of this module, riverpod. The variant brings the providers of the feature's screens. A provider that needs a service of the DI container gets it in the feature's composition file, through a bridge such as Provider<CounterStore>((_) => resolve<CounterStore>()). The variant depends on flutter_riverpod with the constraint any, so the version comes from this module. See Write a feature module.
The ProviderScope and other wrappers
The ProviderScope has to be above every widget that reads a provider. Other modules can wrap the root widget too, and their wrappers come in the order of their modules: a module comes after the providers of the roles it requires and after the modules it depends on. A module can use Riverpod only through its variant for riverpod, which makes it require the state management role, or by depending on this module. Either way it comes after riverpod, so its wrapper always goes inside the ProviderScope.
Choosing it
smf create asks which module manages the state of the app, and offers bloc and None as well. To choose it without the question:
smf create my_app -m riverpod
An app has at most one module that manages its state.