Prinsip reka bentuk di sebalik miniriverpod.
Pakej ini sengaja mengecilkan ciri untuk memastikan tingkah laku kekal jelas: identiti provider mengikut args, suntikan berlingkup melalui Scope, dan semantik pelepasan yang boleh dijangka.
Apa yang Berubah daripada Riverpod
Daripada kelas family yang dijana dan saluran notifier implisit, miniriverpod lebih memilih subclass + args + invoke eksplisit.
Identiti provider
runtimeType + args hash
alternatif family
Jadikan Provider / AsyncProvider sebagai subclass dan hantar super.args((...))
DI sandaran
Scope<T>.required + overrideWithValue
Mengapa ini penting
Anda boleh membuat pertimbangan tentang equality dan override daripada konstruktor Dart biasa, yang menjadikan debugging dan ujian lebih mudah.
Identiti Provider dengan args
args mentakrifkan kunci provider, jadi args yang sama bermakna entri cache yang sama dalam ProviderContainer.
Peraturan identiti
Implikasi praktikal
- Tiada jenis family khusus diperlukan.
- Override mengikut argumen dilakukan dengan mencipta instance provider.
- Kekalkan args stabil dan tidak berubah untuk caching yang boleh dijangka.
Contoh: provider seperti family + sandaran Scope
Gunakan argumen konstruktor sebagai identiti dan suntik instance sandaran melalui 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);
}
}
// Suntik
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Langkah Seterusnya
Provider dan Bacaan
Lihat corak konkrit untuk watch/read/listen dan AsyncProvider.future.
Buka Provider