Designprincipperne bag miniriverpod.
Pakken indsnævrer bevidst funktionerne for at holde adfærden eksplicit: provider-identitet via args, scoped injektion og forudsigelig disposal-adfærd.
Hvad ændrer sig fra Riverpod
I stedet for genererede family-klasser og implicitte notifier-kanaler foretrækker miniriverpod subklasse + args + eksplicit invoke.
Provider-identitet
runtimeType + args-hash
family-alternativ
Lav en subklasse af Provider / AsyncProvider, og kald super.args((...)).
DI-fallback
Scope<T>.required + overrideWithValue
Hvorfor det betyder noget
Du kan ræsonnere om lighed og overrides ud fra almindelige Dart-konstruktører, hvilket gør fejlfinding og tests ligetil.
Provider-identitet med args
args definerer provider-nøglen, så ens args betyder samme cachepost i en ProviderContainer.
Identitetsregel
Praktiske konsekvenser
- Ingen dedikeret family-type er nødvendig.
- Override pr. argument sker ved at oprette provider-instanser.
- Hold args stabile og uforanderlige for forudsigelig caching.
Eksempel: family-lignende provider + Scope-fallback
Brug et konstruktørargument som identitet, og indsæt en fallback-instans 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);
}
}
// Injektion
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Næste skridt
Providers og læsning
Se konkrete mønstre for watch/read/listen og AsyncProvider.future.
Åbn ProvidersMutationer
Implementer tilstandsopdateringer med mutationstokens, mutate og ref.invoke.
Åbn mutationer