Parimet e dizajnit pas miniriverpod.
Paketa i ngushton qëllimisht veçoritë për ta mbajtur sjelljen të qartë: identiteti i provider-it sipas args, injektim i kufizuar në scope dhe semantikë e parashikueshme e heqjes.
Çfarë ndryshon nga Riverpod
Në vend të klasave family të gjeneruara dhe kanaleve të nënkuptuara të notifier-it, miniriverpod preferon subclass + args + invoke të qartë.
Identiteti i provider-it
runtimeType + hash i args
alternativa family
Nënklasifiko Provider / AsyncProvider dhe kalo super.args((...))
DI rezervë
Scope<T>.required + overrideWithValue
Pse ka rëndësi kjo
Mund të arsyetosh për barazinë dhe override-et nga konstruktorët e thjeshtë Dart, gjë që e mban debugging-un dhe testet të drejtpërdrejta.
Identiteti i provider-it me args
args përcakton çelësin e provider-it, kështu që args të barabartë do të thonë i njëjti entry cache brenda një ProviderContainer.
Rregulli i identitetit
Pasojat praktike
- Nuk kërkohet një tip i dedikuar family.
- Override për çdo argument bëhet duke krijuar instanca provider-i.
- Mbaji args të qëndrueshme dhe të pandryshueshme për caching të parashikueshëm.
Shembull: provider i ngjashëm me family + rezervë Scope
Përdorni një argument të konstruktorit si identitet dhe injektoni një instancë rezervë përmes 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);
}
}
// Injekto
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Hapat e ardhshëm
Provider-ët dhe leximet
Shiko modele konkrete për watch/read/listen dhe AsyncProvider.future.
Hap provider-ët