You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I have found that in most places in my app, I want to use .unwrapPrevious() on AsyncValues so that the UI correctly reverts to a not interactive loading state when connection to some service (embedded hardware with websockets interface) used by my app is lost.
It is a real time application, so I don't use offline first design. The connection is robust enough to never drop out randomly, but it can disconnect if there is a firmware crash or I load a new firmware version during development. While the connection is not present, most UI is grayed out until the hardware connects again.
If I forget to write .unwrapPrevious, then the UI will look like it's still usable, even though the connection to the hardware has been lost, and every operation the user might attempt will error out.
Describe the solution you'd like
Add some kind of compile time option to invert the default and modified behaviour of using the previous state.
New option off (default, current behaviour):
Extra typing is required to disable using the previous state.
AsyncValue.valueOrNull: Return current value or previous value if current state is error or loading.
AsyncValue.unwrapPrevious().valueOrNull: Return value only if current state is data.
New option on (explicitly enabled, proposed behaviour):
Extra typing is required to enable using the previous state.
AsyncValue.valueOrNull: Return value only if current state is data.
AsyncValue.withPrevious().valueOrNull: Return current value or previous value if current state is error or loading.
Similar changes to every other function that uses the previous value by default in the current implementation.
Describe alternatives you've considered
We can just make sure to type .unwrapPrevious everywhere, but it's too error prone.
Additional context
Another request for the same feature in an old comment: #2097 (comment).
The text was updated successfully, but these errors were encountered:
just make your own extension method with the logic you want?
i have my own Widget widgetWhen(Widget Function(T) whenData, {/*optional loading and error overrides*/}) that injects my loading and error widgets for me, and I can specify what logic I want.
you could easily just ensure it acts however you like.
Is your feature request related to a problem? Please describe.
I have found that in most places in my app, I want to use
.unwrapPrevious()
onAsyncValue
s so that the UI correctly reverts to a not interactive loading state when connection to some service (embedded hardware with websockets interface) used by my app is lost.It is a real time application, so I don't use offline first design. The connection is robust enough to never drop out randomly, but it can disconnect if there is a firmware crash or I load a new firmware version during development. While the connection is not present, most UI is grayed out until the hardware connects again.
If I forget to write
.unwrapPrevious
, then the UI will look like it's still usable, even though the connection to the hardware has been lost, and every operation the user might attempt will error out.Describe the solution you'd like
Add some kind of compile time option to invert the default and modified behaviour of using the previous state.
New option off (default, current behaviour):
Extra typing is required to disable using the previous state.
AsyncValue.valueOrNull
: Return current value or previous value if current state is error or loading.AsyncValue.unwrapPrevious().valueOrNull
: Return value only if current state is data.New option on (explicitly enabled, proposed behaviour):
Extra typing is required to enable using the previous state.
AsyncValue.valueOrNull
: Return value only if current state is data.AsyncValue.withPrevious().valueOrNull
: Return current value or previous value if current state is error or loading.Similar changes to every other function that uses the previous value by default in the current implementation.
Describe alternatives you've considered
We can just make sure to type
.unwrapPrevious
everywhere, but it's too error prone.Additional context
Another request for the same feature in an old comment: #2097 (comment).
The text was updated successfully, but these errors were encountered: