Principios de diseño detrás de miniriverpod.
El paquete reduce intencionalmente las funciones para mantener el comportamiento explícito: identidad del provider por args, inyección con Scope y semántica de disposición predecible.
Qué cambia respecto a Riverpod
En lugar de clases family generadas y canales de notificación implícitos, miniriverpod prefiere subclase + args + invoke explícito.
Identidad del provider
runtimeType + hash de args
Alternativa a family
Crea una subclase de Provider / AsyncProvider y pasa super.args((...)).
Fallback de DI
Scope<T>.required + overrideWithValue
Por qué importa
Puedes razonar sobre la igualdad y las sobrescrituras con constructores Dart normales, lo que mantiene la depuración y las pruebas sencillas.
Identidad del provider con args
args define la clave del provider, así que unos args iguales significan la misma entrada de caché dentro de un ProviderContainer.
Regla de identidad
Consecuencias prácticas
- No hace falta un tipo family dedicado.
- La sobrescritura por argumento se hace creando instancias del provider.
- Mantén los args estables e inmutables para un caché predecible.
Ejemplo: provider tipo family + respaldo mediante Scope
Usa un argumento del constructor como identidad e inyecta una instancia de respaldo mediante 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);
}
}
// Inyección
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Siguientes pasos
Providers y lecturas
Consulta patrones concretos para watch/read/listen y AsyncProvider.future.
Abrir ProvidersMutaciones
Implementa actualizaciones de estado con tokens de mutación, mutate y ref.invoke.
Abrir Mutaciones