اصول طراحی پشت miniriverpod.
این بسته عمداً قابلیتها را محدود میکند تا رفتارها صریح بمانند: هویت provider بر پایهٔ args، تزریق با Scope و معنای پیشبینیپذیر dispose.
چه چیزهایی نسبت به Riverpod تغییر میکند
بهجای کلاسهای family تولیدشده و کانالهای notifier ضمنی، miniriverpod زیرکلاس + args + invoke صریح را ترجیح میدهد.
هویت Provider
runtimeType + هش args
جایگزین family
یک زیرکلاس از Provider / AsyncProvider بسازید و super.args((...)) را پاس دهید.
DI پشتیبان
Scope<T>.required + overrideWithValue
چرا این مهم است
میتوانید برابری و overrideها را از سازندههای معمول Dart استنباط کنید؛ این کار اشکالزدایی و تستها را ساده نگه میدارد.
هویت Provider با args
args کلید provider را تعریف میکند، پس argsهای برابر یعنی همان ورودی کش داخل ProviderContainer.
قانون هویت
پیامدهای عملی
- به نوع family جداگانهای نیاز نیست.
- بازنویسی برای هر آرگومان با ساختن نمونههای provider انجام میشود.
- برای کشِ پیشبینیپذیر، argsها را پایدار و تغییرناپذیر نگه دارید.
نمونه: provider شبیه family + fallback با Scope
از آرگومان سازنده بهعنوان هویت استفاده کنید و یک نمونهٔ fallback را از طریق 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);
}
}
// تزریق
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
گامهای بعدی
خواندن Providerها
الگوهای مشخص watch/read/listen و AsyncProvider.future را ببینید.
باز کردن ProviderهاMutationها
بهروزرسانیهای وضعیت را با mutation tokenها، mutate و ref.invoke پیادهسازی کنید.
باز کردن Mutationها