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

AutoDisposeNotifierProvider causing state loss #3535

Closed
LeonardoRosaa opened this issue May 9, 2024 · 3 comments
Closed

AutoDisposeNotifierProvider causing state loss #3535

LeonardoRosaa opened this issue May 9, 2024 · 3 comments
Assignees
Labels
bug Something isn't working question Further information is requested

Comments

@LeonardoRosaa
Copy link
Contributor

Describe the bug
The AutoDisposeNotifierProvider leads to a state loss when performing an operation that triggers a state change in the notifier and attempts to retrieve the state afterward.

The initial state of providerAProvider is State.initial, and the expected behavior is for the await ref.read(providerAProvider.notifier).change(); operation to transition the state to State.success rather than staying at State.initial. For instance:

await ref.read(providerAProvider.notifier).change();

if (kDebugMode) {
    print(ref.read(providerAProvider)); // Expect State.success
} 

To Reproduce
Run the code in the link below:

https://github.com/LeonardoRosaa/riverpod-state-loss

Expected behavior
It's expected that the Riverpod keeps the state while the widget is alive.

@rrousselGit
Copy link
Owner

Isn't that the whole point of autoDispose?
You need to ref.watch a provider to preserve the state

@rrousselGit rrousselGit added question Further information is requested and removed needs triage labels May 10, 2024
@LeonardoRosaa
Copy link
Contributor Author

I understand - but would preserving the state while the widget is alive be a good approach? There may be cases where the ref.watch is unnecessary.

@rrousselGit
Copy link
Owner

If you want to preserve the state, use ref.watch or ref.listen. That's part of their purpose.

What you described is clearly a case of ref.watch being necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants