Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to ignore previous state in AsyncValue by default #3670

Open
Barabas5532 opened this issue Jul 23, 2024 · 3 comments
Open

Option to ignore previous state in AsyncValue by default #3670

Barabas5532 opened this issue Jul 23, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@Barabas5532
Copy link

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).

@rrousselGit
Copy link
Owner

There's already the parameter asReload: true on ref.invalidate/invalidateSelf in the 3.0 branch, which kind of does that.

But to begin with, there's already AsyncValue.isRefreshing/isLoading. So you can write logic based on that.

For instance, you could do:

extension<T> on AsyncValue<T> {
  T? get currentValue => isRefreshing ? null : valueOrNull;
}

@rrousselGit
Copy link
Owner

Overall you're not really meant to use unwrapPrevious. You're supposed to use pattern matching to react to loading/error states.

@rrousselGit rrousselGit added question Further information is requested and removed needs triage labels Jul 24, 2024
@TekExplorer
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants