bloc

bloc copied to clipboard

I would just like to add a suggestion to implement the bloc library with riverpod which is more comfortable than the provider package. Since the bloc package depends on the provider library it will be more useful if bloc library is implemented with riverpod which is a kind of enhanced provider.

This idea was inspired by this package called riverBloc: https://pub.dev/packages/riverbloc and I also feel that it would be a breaking change and will increase the performance of the provider package a lot.

Hi @pythonhubpy 👋 Thanks for opening an issue!

There is an open discussion regarding this topic at https://github.com/kranfix/riverbloc/issues/11 👍

@pythonhubpy  The idea behind riverbloc is to avoid the dependence on context, not to be more efficient because the difference won't be relevant.

Thanks for consider my package as a good proposal.

Hey @felangel,

currently in the phase of deciding on the state management solution for our new app. After doing some research, it seems to me that using a combination of RiverPod und Cubits will be the best solution. That's why I found: https://github.com/kranfix/riverbloc.

In this comment you have mentioned that you are thinking about working with riverpod, but you don't want to do it, because riverpod is not mature yet. This comment was about 7 month ago and riverpod now has over 1.5k Stars. So I want to ask what your thoughts are now?

Rigth now I have the choice to either:

1. use riverbloc => Once riverpod get's incorporated, into bloc I need to migrate
2. use bloc how it is right now => Once riverpod get's incorporated, into bloc I need to migrate
3. You create another package let's call it "river_pod_bloc", that can be used together with bloc => Once riverpod get's incorporated, into bloc the migration will be very easy
4. You incorporate riverpod into bloc right away => No migration needed

So I don't really know right now, what to do because I don't know what the your plans are. Maybe you could give me a little bit advice on this decision using your insights.

Thanks,

Niklas

PS: This is the 3th most upvoted issue in the repo, if you exclude https://github.com/felangel/bloc/issues/139 and https://github.com/felangel/bloc/issues/1819, which are not really feature request.

@felangel, I'm open to your ideas to drive riverbloc to be a package that can be integrated to https://bloclibrary.dev/ if you agree. I maintain it continuously and adding more functinalities.

@omidraha please could you say how fountain can help in this feature request?
fountain has different approach to riverpod to inject dependencies and differs from bloc in that it handles a global state (personally I prefer many blocs to be able to have an easy reuse of code in other projects) and only takes inspiration about how to use streams.

I also don't understand how this should be helpful.

Are there any updates on this issue?

@HerrNiklasRaab In your experience, would using Riverpod + StateNotifier (via StateNotifierProvider) differ much from using Riverpod + Cubit, via the potential CubitProvider? I have quite some experience with Bloc/Cubit and my last private app is with Riverpod (just because I wanted to get my hands dirty with it) and I was under the impression StateNotifier is pretty much a Cubit. (Bloc is a bit different as it has the concept of an event stream.)

StateNotifier is very similar to Cubit, but Cubit is asynchronous. In riverbloc package, you can find a BlocProvider that works with both Bloc and Cubit (or any BlocBase).

What would be the advantages for Cubit to be asynchronous?

StateNotifier is very similar to Cubit, but Cubit is asynchronous. In riverbloc package, you can find a BlocProvider that works with both Bloc and Cubit (or any BlocBase).

@lhmzhou There is no advantage in the async vs sync. The real advantage is onChange that let you track how your states change. I could be implemented for StateNotifier, but currently it isn't.

@lhmzhou There is no advantage in the async vs sync. The real advantage is onChange that let you track how your states change. I could be implemented for StateNotifier, but currently it isn't.

What onChange?

StateNotifier has an addListener method. And Riverpod has both ref.listen(provider, onChange) and ProviderObserver.didUpdateProvider. That should cover all "on change event" use-cases

@felangel I'm using bloc in production, and I must say it's the finest state management library available for our app's architecture, however there's too much reliance on context, which may be frustrating at times. I'd like to see bloc implementation with Riverpod as well. It has been over a year and a half since this problem was opened; please let us know if there has been any progress.

@felangel I'm using bloc in production, and I must say it's the finest state management library available for our app's architecture, however there's too much reliance on context, which may be frustrating at times. I'd like to see bloc implementation with Riverpod as well. It has been over a year and a half since this problem was opened; please let us know if there has been any progress.

You can already use the two together using package:riverbloc. Hope that helps 👍

@felangel Any plans to pull riverbloc into the official bloc package?

@felangel Any plans to pull riverbloc into the official bloc package?

As of now no. Even if provider were to be deprecated, I'd prefer to maintain the existing API and revert back to using InheritedWidget (which is how flutter_bloc was originally implemented).

@felangel Any plans to pull riverbloc into the official bloc package?

As of now no. Even if provider were to be deprecated, I'd prefer to maintain the existing API and revert back to using InheritedWidget (which is how flutter_bloc was originally implemented).

Got it thanks!

Closing this since there are currently no plans to migrate to riverpod. Anyone who prefers to use bloc with riverpod can feel free to use the riverbloc package.