miniriverpod-ի հետևում գտնվող նախագծման սկզբունքները։
Փաթեթը միտումնավոր սահմանափակում է հնարավորությունները, որպեսզի վարքագիծը լինի հստակ՝ provider-ի ինքնություն ըստ args-ի, Scope-ի միջոցով ինյեկցում և կանխատեսելի հեռացման սեմանտիկա։
Ինչ է փոխվում Riverpod-ից
Գեներացված family դասերի և implicit notifier ալիքների փոխարեն miniriverpod-ը նախընտրում է ենթադաս + args + explicit invoke մոտեցումը։
Provider-ի ինքնություն
runtimeType + args hash
family-ի այլընտրանք
Provider / AsyncProvider-ը դարձրեք ենթադաս և փոխանցեք super.args((...))
DI պահուստ
Scope<T>.required + overrideWithValue
Ինչու է սա կարևոր
Հավասարության և override-ների մասին կարելի է դատել սովորական Dart կոնստրուկտորներից, ինչը debugging-ը և tests-ը դարձնում է պարզ։
Provider-ի ինքնությունը args-ով
args-ը սահմանում է provider-ի բանալին, ուստի նույն args-ը նշանակում է նույն cache-ի գրառումը ProviderContainer-ի ներսում։
Ինքնության կանոն
Գործնական հետևանքներ
- Առանձին family type անհրաժեշտ չէ։
- Յուրաքանչյուր արգումենտի համար override-ը կատարվում է provider-ի instance-ներ ստեղծելով։
- Պահեք args-ը կայուն և անփոփոխ՝ կանխատեսելի cache-ի համար։
Օրինակ՝ family-ին նման provider + Scope պահուստ
Օգտագործեք կոնստրուկտորի արգումենտը որպես ինքնություն և Scope-ի միջոցով ներմուծեք պահուստային instance։
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);
}
}
// Ներմուծում
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Հաջորդ քայլերը
Provider-ներ և ընթերցումներ
Տեսեք watch/read/listen և AsyncProvider.future-ի կոնկրետ օրինակները։
Բացել provider-ներըՓոփոխություններ
Իրականացրեք վիճակի թարմացումներ mutation token-ներով, mutate-ով և ref.invoke-ով։
Բացել փոփոխությունները