Designprinzipien hinter miniriverpod.
Das Paket schränkt die Funktionen bewusst ein, um das Verhalten explizit zu halten: Provider-Identität über args, Scope-Injektion und vorhersehbare Disposal-Semantik.
Was sich im Vergleich zu Riverpod ändert
Statt generierter family-Klassen und impliziter Notifier-Kanäle bevorzugt miniriverpod Subklasse + args + explizites invoke.
Provider-Identität
runtimeType + args-Hash
family-Alternative
Leite von Provider / AsyncProvider ab und übergib super.args((...)).
DI-Fallback
Scope<T>.required + overrideWithValue
Warum das wichtig ist
Du kannst Gleichheit und Overrides anhand normaler Dart-Konstruktoren nachvollziehen, was Debugging und Tests einfach macht.
Provider-Identität mit args
args definiert den Provider-Schlüssel, daher bedeuten gleiche args denselben Cache-Eintrag in einem ProviderContainer.
Identitätsregel
Praktische Konsequenzen
- Kein eigener family-Typ erforderlich.
- Ein Override pro Argument erfolgt durch das Erzeugen von Provider-Instanzen.
- Halte args stabil und unveränderlich für vorhersehbares Caching.
Beispiel: family-ähnlicher Provider + Scope-Fallback
Nutze ein Konstruktionsargument als Identität und injiziere eine Fallback-Instanz über 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);
}
}
// Einfügen
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Nächste Schritte
Provider und Lesezugriffe
Sieh dir konkrete Muster für watch/read/listen und AsyncProvider.future an.
Provider öffnenMutationen
Implementiere Zustandsaktualisierungen mit Mutation-Tokens, mutate und ref.invoke.
Mutationen öffnen