Designprinsippene bak miniriverpod.
Pakken snevrer med vilje inn funksjonene for å holde atferden eksplisitt: provider-identitet via args, scoped injeksjon og forutsigbar disposal-semantikk.
Hva som endrer seg fra Riverpod
I stedet for genererte family-klasser og implisitte notifier-kanaler foretrekker miniriverpod subclass + args + eksplisitt invoke.
Provider-identitet
runtimeType + args hash
family-alternativ
Subclass Provider / AsyncProvider og send super.args((...))
DI-fallback
Scope<T>.required + overrideWithValue
Hvorfor dette betyr noe
Du kan resonnere om likhet og overrides ut fra vanlige Dart-konstruktører, noe som gjør feilsøking og tester rett fram.
Provider-identitet med args
args definerer providersnøkkelen, så like args betyr samme cache-oppføring i en ProviderContainer.
Identitetsregel
Praktiske konsekvenser
- Ingen egen family-type er nødvendig.
- Overstyring per argument gjøres ved å opprette providerinstanser.
- Hold args stabile og uforanderlige for forutsigbar caching.
Eksempel: family-lignende provider + Scope-fallback
Bruk et konstruktørargument som identitet, og injiser en fallback-instans gjennom 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);
}
}
// Sett inn
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Neste steg
Providere og lesing
Se konkrete mønstre for watch/read/listen og AsyncProvider.future.
Åpne providereMutasjoner
Implementer statusoppdateringer med mutation tokens, mutate og ref.invoke.
Åpne mutasjoner