Replies: 3 comments 1 reply
|
Workaround For now we add the following line to our Widget.build() override: This resolves the issue, but it's still not clear why the original ref.read() call disposes early, ideally it wouldn't. |
|
The issue is caused by the pause mechanism of invisible widgets. I am facing the same issue but in providers rather than widgets. In my app, providers are using other providers. It's not just a provider being used in a widget. I tried using If anyone has a better idea of how to approach this, it would be much appreciated. |
|
I think this is the issue mentioned here: #3745 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I may be misusing the API, looking to get some guidance.
Code Example
Logs
Issue
I expected
build: disposedto be afterdoSideEffect: done data side effect.Ie
sideEffectProvidershould not be disposed until_onUserAction()is done with it.Should I be doing this differently?
Edit: this logic used to work fine in Riverpod v2, and broke in v3, probably related to:
https://riverpod.dev/docs/whats_new#refs-and-notifiers-can-no-longer-be-interacted-with-after-they-have-been-disposed
Thanks,
Mash.
All reactions