Closed andcea closed 1 year ago
ProxyProviders was IMO a terrible idea.
The API is poorly designed and doesn't quite solve the problem.
I do not want to implement a new one.
I'd suggest using pkg:riverpod instead anyway. It solves object composition in a much better way.
@rrousselGit can you please then suggest a workaround or an opinion on the ones suggested above?
Moving to riverpod is not an option for everyone.
Also, why do you say ProxyProviders was a terrible idea?
You could use StateNotifier.addListener
to combine two statenotifiers.
ProxyProviders aren't very intuitive, both lots of duplicate + possible mistakes, and lack flexibility. Your state could get destroyed too often with no easy way to fix that.
Is your feature request related to a problem? Please describe. I'd like to be able to create a state notifier (using
provider
) based on external dependencies that can change.Describe the solution you'd like An API similar to
ProxyProvider
orChangeNotifierProxyProvider
would be great. For example:Describe alternatives you've considered
I'm not sure how correct this is. Given that providing the notifier is lazy, I think if we first request the notifier from a
context
that doesn't havewatch
access (i.e.onTap
), thenfinal notifier = context.watch<MyStateNotifier>()
will throw. It also means that thestate
will be provided eagerly (once the notifier is requested).Something better might be:
This has the advantage that providing both the
notifier
andstate
is lazy however,DeferredInheritedProvider
doesn't currently take anupdate
parameter (onlycreate
).I'm not sure if there are any other workarounds for this solution.