Designprinciperna bakom miniriverpod.
Paketet begränsar medvetet funktionerna för att hålla beteendet explicit: provider-identitet via args, scoped injektion och förutsägbar disposal-semantik.
Vad som ändras jämfört med Riverpod
I stället för genererade family-klasser och implicita notifier-kanaler föredrar miniriverpod subclass + args + explicit invoke.
Provider-identitet
runtimeType + args-hash
family-alternativ
Subclassa Provider / AsyncProvider och skicka super.args((...))
DI-fallback
Scope<T>.required + overrideWithValue
Varför detta spelar roll
Du kan resonera om likhet och overrides utifrån vanliga Dart-konstruktörer, vilket gör felsökning och tester enkla.
Provider-identitet med args
args definierar provider-nyckeln, så lika args betyder samma cachepost i en ProviderContainer.
Identitetsregel
Praktiska konsekvenser
- Ingen dedikerad family-typ behövs.
- Överskrivning per argument görs genom att skapa providerinstanser.
- Håll args stabila och oföränderliga för förutsägbar cachning.
Exempel: family-lik provider + Scope-fallback
Använd ett konstruktörsargument som identitet och injicera 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);
}
}
// Infoga
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Nästa steg
Providers och läsning
Se konkreta mönster för watch/read/listen och AsyncProvider.future.
Öppna providersMutationer
Implementera tillståndsuppdateringar med mutation tokens, mutate och ref.invoke.
Öppna mutationer