-
-
Notifications
You must be signed in to change notification settings - Fork 908
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
docs: Providers are not paused properly if no longer listened. #3460
Comments
I think you're confused about what "the provider is paused" means. For instance consider: final provider = Provider((ref) {
print('rebuild');
Timer(Duration(seconds: 2), () => ref.invalidateSelf());
}); This provider will print Yet you'll notice that if you do a simple |
In your snippet, the provider is correctly paused. This can be checked with class DetailsNotifier extends Notifier<int> {
@override
int build() {
print('start');
ref.onResume(() {
print('resume');
});
ref.onCancel(() {
print('pause');
});
...
}
} You'll see that when popping the detail page, Your specific issue is: The solution in your case is to manually cancel the subscription: ProviderSubscription? sub = ref.listen(appNotipod, (previous, next) {
print('Listen appNotipod ${DateTime.now()}');
});
// Stop listening on pause
ref.onCancel(() => sub?.cancel());
// Restart the listening on resume
ref.onResume(() => sub = ref.listen(appNotipod, (previous, next) {
print('Listen appNotipod ${DateTime.now()}');
})); v3 will make this more straightforward as you'll be able to do: final sub = ref.listen(appNotipod, (previous, next) {
print('Listen appNotipod ${DateTime.now()}');
});
ref.onCancel(sub.pause);
// Restart the listening on resume
ref.onResume(sub.resume); |
We could consider making a breaking change for 3.0, and have ref.listen(p, maintainSubscriptionOnCancel: true, ...); |
In any case, the pausing mechanism is receiving a big overhaul in 3.0. So that docs page will likely receive a lot of change for 3.0 :) |
I see, so the pausing relates more to the body of the provider. If it just returns a complex object like I would suggest maybe renaming Thank you for the clarification! |
This would be an interesting concept and would offer more control over background services held by providers. |
I named it |
It makes sense, but aren't we unable to resume a |
No we can. There's "StreamSubscription.resume" and the controller.onResume lifecycle And "dispose" would be more like |
hooks_riverpod: v2.5.1
Describe what scenario you think is uncovered by the existing examples/articles
Providers are not paused when no longer listened as stated in the docs but they can be disposed if
.autoDispose
is specified.Describe why existing examples/articles do not cover this case
Source
I understand that Riverpod is currently undergoing a major rewrite, and I'm aware that some parts of the documentation may be outdated. However, it seems to me that this concept forms the backbone of how Provider operates and doesn't appear to have changed or will change. Is this correct?
From the docs:
Additional context
I created a reproducible example, when you press "Push Details" then "Pop Details" and start updating
appNotipod
, listener will be triggered insidedetailsNotipod
but it shouldn't as stated in the docs because it must be paused.Because of the way lifecycle of providers, workarounds like EagerInitialization exist, we need to watch for providers at the root of the app so they are not paused, but if this is not the case and providers are not paused when no longer listened we don't need EagerInitialization.
Example
Is it a bug or outdated docs?
The text was updated successfully, but these errors were encountered: