Princípios de design por trás do miniriverpod.
O pacote restringe intencionalmente os recursos para manter o comportamento explícito: identidade do provider por args, injeção com escopo e semântica previsível de descarte.
O que muda em relação ao Riverpod
Em vez de classes family geradas e canais de notificação implícitos, o miniriverpod prefere subclass + args + invoke explícito.
Identidade do provider
runtimeType + hash de args
alternativa a family
Subclasse Provider / AsyncProvider e passe super.args((...))
fallback de DI
Scope<T>.required + overrideWithValue
Por que isso importa
Você pode raciocinar sobre igualdade e overrides a partir de construtores Dart simples, o que mantém depuração e testes diretos.
Identidade do provider com args
args define a chave do provider, então args iguais significam a mesma entrada de cache dentro de um ProviderContainer.
Regra de identidade
Consequências práticas
- Nenhum tipo family dedicado é necessário.
- A substituição por argumento é feita criando instâncias de provider.
- Mantenha args estáveis e imutáveis para um cache previsível.
Exemplo: provider semelhante a family + fallback via Scope
Use um argumento do construtor como identidade e injete uma instância de fallback por meio do 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);
}
}
// Injetar
ProviderScope(
overrides: [
ProductProvider.fallback.overrideWithValue(ProductProvider(search: 'jeans')),
],
child: const App(),
);
Próximos passos
Providers e leituras
Veja padrões concretos para watch/read/listen e AsyncProvider.future.
Abrir providersMutações
Implemente atualizações de estado com tokens de mutação, mutate e ref.invoke.
Abrir mutações