Ontwerpprincipes achter miniriverpod.
Het pakket beperkt functies bewust om het gedrag expliciet te houden: provider-identiteit via args, scoped injectie en voorspelbare disposal-semantiek.
Wat er verandert ten opzichte van Riverpod
In plaats van gegenereerde family-klassen en impliciete notifier-kanalen kiest miniriverpod voor subclass + args + expliciete invoke.
Provider-identiteit
runtimeType + args hash
family-alternatief
Subklasseer Provider / AsyncProvider en geef super.args((...)) door.
DI-fallback
Scope<T>.required + overrideWithValue
Waarom dit belangrijk is
Je kunt gelijkheid en overrides afleiden uit gewone Dart-constructors, wat debuggen en testen eenvoudig houdt.
Provider-identiteit met args
args definieert de providersleutel, dus gelijke args betekenen dezelfde cachevermelding binnen een ProviderContainer.
Identiteitsregel
Praktische gevolgen
- Geen aparte family-type is nodig.
- Overschrijven per argument gebeurt door providerinstanties te maken.
- Houd args stabiel en onveranderlijk voor voorspelbare caching.
Voorbeeld: family-achtige provider + Scope-fallback
Gebruik een constructorargument als identiteit en injecteer een fallbackinstantie via Scope.
class ProductProvider extends AsyncProvider<List<Product>> {
ProductProvider({this.search = ''}) : super.args((search,));
final String search;
static final fallback = Scope<ProductProvider>.required('product.fallback');
@override
FutureOr<List<Product>> build(ref) async {
final api = ref.watch(productsApiProvider);
return api.search(q: search);
}
}
// Invoegen
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Volgende stappen
Providers en reads
Bekijk concrete patronen voor watch/read/listen en AsyncProvider.future.
Providers openen