miniriverpod ಹಿಂದಿನ ವಿನ್ಯಾಸ ತತ್ವಗಳು.
ಪ್ಯಾಕೇಜ್ ವರ್ತನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಲು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ: args ಆಧಾರಿತ provider ಗುರುತು, Scope ಮೂಲಕ scope ಮಾಡಿದ ಇಂಜೆಕ್ಷನ್, ಮತ್ತು ಊಹಿಸಬಹುದಾದ disposal semantics.
Riverpod ನಿಂದ ಏನು ಬದಲಾಗುತ್ತದೆ
generated family classes ಮತ್ತು implicit notifier channels ಬದಲಾಗಿ, miniriverpod subclass + args + explicit invoke ಅನ್ನು ಇಷ್ಟಪಡುತ್ತದೆ.
Provider identity
runtimeType + args hash
family alternative
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.
Identity rule
ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮಗಳು
- ವಿಶೇಷವಾದ family type ಅಗತ್ಯವಿಲ್ಲ.
- ಪ್ರತಿ argument override ಅನ್ನು provider instances ರಚಿಸುವ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.
- ಊಹಿಸಬಹುದಾದ caching ಗಾಗಿ args ಸ್ಥಿರವಾಗಿಯೂ immutable ಆಗಿಯೂ ಇರಲಿ.
ಉದಾಹರಣೆ: family-ನಂತೆ provider + Scope fallback
constructor argument ಅನ್ನು ಗುರುತಿನಾಗಿ ಬಳಸಿ ಮತ್ತು Scope ಮೂಲಕ fallback instance ಅನ್ನು ಸೇರಿಸಿ.
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(),
);
ಮುಂದಿನ ಹಂತಗಳು
Providerಗಳು ಮತ್ತು ಓದುಗಳು
watch/read/listen ಮತ್ತು AsyncProvider.future ಗಾಗಿ ನಿಖರ ಮಾದರಿಗಳನ್ನು ನೋಡಿ.
Providerಗಳನ್ನು ತೆರೆಯಿರಿಮ್ಯೂಟೇಶನ್ಗಳು
mutation tokens, mutate, ಮತ್ತು ref.invoke ಬಳಸಿ state updates ಅನ್ನು ಜಾರಿಗೊಳಿಸಿ.
ಮ್ಯೂಟೇಶನ್ಗಳನ್ನು ತೆರೆಯಿರಿ