Дизајнерски принципи зад miniriverpod.
Пакетот намерно ги стеснува можностите за однесувањето да остане експлицитно: идентичност на провајдерот по args, инјекција преку Scope и предвидлива семантика на ослободување.
Што се менува во однос на Riverpod
Наместо генерирани family класи и имплицитни notifier канали, miniriverpod претпочита подкласа + args + експлицитен invoke.
Provider identity
runtimeType + args hash
family alternative
Подкласирајте Provider / AsyncProvider и пренесете super.args((...))
DI fallback
Scope<T>.required + overrideWithValue
Зошто е ова важно
Можете да резонирате за еднаквоста и override-ите од обични Dart конструктори, што ги прави дебагирањето и тестовите едноставни.
Идентитет на провајдер со args
args го дефинира клучот на провајдерот, па исти args значат ист запис во кешот во ProviderContainer.
Identity rule
Практични последици
- Не е потребен посебен family тип.
- Override по аргумент се прави со создавање инстанци на провајдер.
- Чувајте ги args стабилни и immutable за предвидливо кеширање.
Пример: провајдер сличен на family + резервна Scope инстанца
Користете аргумент од конструктор како идентитет и вметнете резервна инстанца преку 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);
}
}
// Inject
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Следни чекори
Провајдери и читања
Погледнете конкретни обрасци за watch/read/listen и AsyncProvider.future.
Отвори провајдериМутации
Имплементирајте ажурирања на состојбата со mutation token-и, mutate и ref.invoke.
Отвори мутации