Principy návrhu za miniriverpodem.
Balíček záměrně zužuje funkce, aby bylo chování explicitní: identita provideru podle args, injektáž přes Scope a předvídatelná semantika disposal.
Co se mění oproti Riverpodu
Místo generovaných family tříd a implicitních notifier kanálů dává miniriverpod přednost subclass + args + explicitní invoke.
Identita provideru
runtimeType + args hash
alternativa k family
Vytvořte subclass Provider / AsyncProvider a předejte super.args((...))
DI fallback
Scope<T>.required + overrideWithValue
Proč je to důležité
O rovnosti a přepsání můžete uvažovat pomocí běžných Dart konstruktorů, což usnadňuje ladění i testy.
Identita provideru s args
args definuje klíč provideru, takže stejné args znamenají stejnou položku cache uvnitř ProviderContainer.
Pravidlo identity
Praktické důsledky
- Není potřeba samostatný typ family.
- Přepsání po argumentu se dělá vytvářením instancí provideru.
- Pro předvídatelné ukládání do cache držte args stabilní a neměnné.
Příklad: provider podobný family + fallback přes Scope
Použijte argument konstruktoru jako identitu a vložte záložní instanci přes 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);
}
}
// Vložení
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Další kroky
Providery a čtení
Podívejte se na konkrétní vzory pro watch/read/listen a AsyncProvider.future.
Otevřít providery