Прынцыпы дызайну miniriverpod.
Пакет наўмысна звужае магчымасці, каб паводзіны заставаліся відавочнымі: ідэнтычнасць provider па args, укараненне праз Scope і прадказальная семантыка знішчэння.
Што змяняецца ў параўнанні з Riverpod
Замест згенераваных family-класаў і няяўных каналаў notifier, miniriverpod аддае перавагу subclass + args + адкрытаму invoke.
Ідэнтычнасць provider
runtimeType + args hash
Альтэрнатыва family
Стварайце падклас Provider / AsyncProvider і перадавайце super.args((...))
Рэзервовы DI-варыянт
Scope<T>.required + overrideWithValue
Чаму гэта важна
Пра роўнасць і override-ы можна разважаць праз звычайныя Dart-канструктары, што робіць адладку і тэсты простымі.
Ідэнтычнасць provider з args
args вызначае ключ provider, таму аднолькавыя args азначаюць адзін і той жа запіс кэша ў ProviderContainer.
Правіла ідэнтычнасці
Практычныя наступствы
- Асобны тып family не патрэбны.
- Перазапіс для кожнага аргумента робіцца праз стварэнне асобнікаў provider.
- Трымайце args стабільнымі і нязменнымі для прадказальнага кэшавання.
Прыклад: provider, падобны да 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);
}
}
// Укараненне
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Наступныя крокі
Providers і чытанне
Паглядзіце канкрэтныя шаблоны для watch/read/listen і AsyncProvider.future.
Адкрыць Providers