Replies: 1 comment
-
That's the gist of the problem, you shouldn't. The recommendation is to have one provider per "get" request. But anyway if you don't care about the AsyncValue, you don't have to call "when". You could call "requireValue" |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I found that the release of
AsyncNotifier
solves in a really good way the old inconvenient of asynchronous initialization (clap, clap for that), but although theAsyncValue
brings the structure for dealing safely with the states of asynchronous tasks by the ui, I also think it might pose as an inconvenient sometimes. If you try to useAsyncNotifier
as state management solution for a more complex object with possibly multiple requests being dealt with, theAsyncValue
structure around the state isn't as useful as in the case of a single request (Or even if your state is comprised of a combination of requests and other synchronous values). It would be possible to create a type ofNotifier
, with asynchronous initialization capability, but without theAsyncValue
structure around the state? Is something like that desirable? It could fit into Riverpod's proposed patterns?I think that would increase the
Notifier
versatility and enlarges a lot the number of possible smoothly accommodated use cases.Beta Was this translation helpful? Give feedback.
All reactions