feat: Expose stream controller onCancel and hasListener

[D-James-GH]

Description

It would be great to know when all active listeners to a bloc are removed or whether there are any listeners to a bloc.

Desired Solution

Expose the stream controller's onCancel callback and hasListener.

Additional Context

This would be useful for removing or changing state when a screen goes out of view. Say you need to have a bloc that wraps the whole app but the state stored is large and is only needed on 2 pages. Right now I would have to put add an event in the dispose method of the page. It would be good if there was a onCancel override similar to onChange. This onCancel could be called when the stream controllers onCancel is called. Having hasListener available would be a nice to have as well.

[felangel]

Hi @D-James-GH 👋
Thanks for opening an issue!

This would be useful for removing or changing state when a screen goes out of view. Say you need to have a bloc that wraps the whole app but the state stored is large and is only needed on 2 pages.

I recommend scoping the bloc to the two pages instead of providing it globally for this exact reason. Why don’t you scope the bloc in this case to just the widgets that need it?

[D-James-GH]

Thank you for the response 🙂

Currently scoping the bloc is our solution and it works fine, however, using the default flutter navigation it is difficult to scope a provider to two screens without using nested navigators, which often come with their own difficulties. Admittedly there are a few packages which can make this easy. However, even with packages such as GoRouter or Auto Route (those are the only two I have some experience with) blocs cannot be scoped around multiple pages if those pages are at different positions in a navigation tree.

By having a callback when the bloc no longer has any listeners it would open up different opportunities for managing state. For example, I might have lots of api state that I want to clean up once it is not used but there might also be some related local state that should be kept.

There definitely are work arounds too much of this, however, it an onCancel hook would be a nice to have and would allow flexibility when caching api requests.

I understand if this is something from an internal point of view that wouldn't be appropriate. Let me know if I am missing something.

[alvaromateo]

Hi,

If I understood correctly I'm having the same (or similar) issue and I was thinking if it would be possible to add a couple of methods.

• pauseEvents
• resumeEvents

This way when you push a new page to the router you could stop receiving events for the Bloc of the page that is now in the background. And when the page is again on top of the stack then resume them.

@felangel if you like this solution/approach I could try to open the PR myself to help you out.