miniriverpod کے پیچھے ڈیزائن اصول۔
یہ پیکج behavior کو واضح رکھنے کے لیے features کو جان بوجھ کر محدود کرتا ہے: args کے ذریعے provider identity، scoped injection، اور قابلِ پیش گوئی disposal semantics۔
Riverpod کے مقابلے میں کیا بدلتا ہے
Generated family classes اور implicit notifier channels کے بجائے miniriverpod subclass + args + explicit invoke کو ترجیح دیتا ہے۔
Provider identity
runtimeType + args hash
family کا متبادل
Provider / AsyncProvider کو subclass کریں اور super.args((...)) پاس کریں
DI fallback
Scope<T>.required + overrideWithValue
یہ کیوں اہم ہے
آپ سادہ Dart constructors سے equality اور overrides کے بارے میں استدلال کر سکتے ہیں، جو debugging اور tests کو سیدھا رکھتا ہے۔
args کے ساتھ Provider شناخت
args provider key متعین کرتا ہے، اس لیے برابر args کا مطلب ProviderContainer کے اندر وہی cache entry ہے۔
شناخت کا اصول
عملی نتائج
- کسی الگ family type کی ضرورت نہیں ہے.
- ہر argument کے لیے override provider instances بنا کر کیا جاتا ہے.
- قابلِ پیش گوئی caching کے لیے args کو مستحکم اور immutable رکھیں.
مثال: family جیسے provider + Scope fallback
Constructor argument کو شناخت کے طور پر استعمال کریں اور Scope کے ذریعے fallback instance inject کریں۔
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(),
);
اگلے مراحل
پرووائیڈرز اور مطالعہ
watch/read/listen اور AsyncProvider.future کے ٹھوس patterns دیکھیں.
پرووائیڈرز کھولیں