-
Notifications
You must be signed in to change notification settings - Fork 16
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
Migrate into bloc #11
Comments
Thanks for appreciate my work. I would like this code to live within the bloc repository (at least the useBloc hook function). By the moment, I am also sending some PR to but with the This modification to the widget tree in the widget inspector will be released tomorrow (v0. 9.0). By the moment, this reduction of the widget tree is available for I hope @felangel is interested in these changes that I am making. |
Hey all, I think there is definitely some interesting work being done but I'm still not entirely convinced that hooks is the direction we should be moving in. It's something that is being actively discussed and I will continue to monitor and experiment with the APIs as well but I don't think it makes sense to try to introduce hooks into the The problem that hooks are solving in this case is providing an alternative to the builder pattern which is very prevalent throughout all of flutter. I would love to discuss some concrete use-cases for which hooks are better suited than builders in the context of the bloc library because generally speaking, there should be one bloc per feature so there should be very few cases where you need to nest BlocBuilders and BlocListeners (features should generally not depend on other features). In my experience having many nested BlocBuilders is usually a symptom of blocs that are data-driven or resource-driven and not feature-driven. Would love to hear everyone's thoughts! Keep up the great work @kranfix and thanks @chimon2000 for starting this conversation! 😄 |
@felangel I agree that hooks are a divisive topic, and I am actually more interested in the non-hooks version that @kranfix is working on vs. the hooks version (check out #12). I think that the problems that riverpod by itself solves (type safety, simplified state composition, simplified testing) are extremely beneficial. |
@chimon2000 yeah I definitely agree and it's something I'm happy to work towards but I am also hesitant about introducing a dependency on |
Totally fair @felangel. I expect this will be an open conversation dependent on when riverpod hits 1.0. I know Remi has mentioned the experimental tag will be dropped soon 🤞 |
I already removed the experimental status actually. Anyway, I'll be blunt: Do we really need BLoC with Riverpod? Genuinely wondering. |
@rrousselGit I think that's a fair question. There are many similarities between the two. I am thinking specifically of users who may already be heavily invested in the bloc ecosystem, but want some of the convenience that riverpod provides. Even in that case they may find, migrating from provider to riverpod not worth the hassle. I suppose the outcome of felangel/bloc#1429 may affect this as well. |
@rrousselGit |
|
@rrousselGit The transitions with Outside of that, I agree with StateNotifier == Cubit, but despite I like riverpod with StateNotifierProvider, I really need Change/Transition and that's the reason why I am working in riverbloc. |
I'd appreciate if you could explain why ProviderObserver is not enough, with a concrete example New features can be added to Riverpod if there is a need. |
Currently, each observer in Then I was thinking in opening an issue/PR with a pair of mixins from StateNotifier: And adding a static |
I don't understand what this means. The previous value could be added to the update event, but I really don't understand what you are trying to do specifically. |
Just stumble on this issue thanks to google, one thing that seems to be missing with the observer on riverpod side as outlined by @kranfix is the current state. There are many cases where it is super useful to have both the current and the new state (time travel, undo - redo, replay, etc...). |
@tlvenn I have been working to create a package with those complements, but time was no my friend in the last 4 weeks. But in December I will upload more stuff, including null-safety |
yes no worry at all, i was merely trying to point out something to @rrousselGit that seemed to be lost in your conversation with him when you started to compare observers and actually the examples i gave would probably be doable if you only have the init value and the new values, that should be enough to build an history stack to replay, undo and the like but I somewhat remember seeing some use cases mainly with mobx when knowing the old value was actually quite handy. |
Also it should be noted on comparing StateNotifier with Cubit that the biggest difference is that the former is based around listeners while the later is stream based and as such compose more naturally with blocs when you need them or other streams. Cubits also provides extension around persistence and behavior (redo/undo) with This is not to say that one is better than the others, there are definitely different tradeoffs with both solutions. I personally prefer the ergonomic of Cubit over StateNotifier / ValueNotifier but that's just me. |
Riverpod has now become stable and has a good amount of users and people have also started switching to riverpod because of it's ease thanks to @rrousselGit so now there could be a consideration to implement bloc with riverpod. According to my thoughts. |
migrating Bloc FROM |
I really love what you are doing here, as I have been exploring how to use bloc w/ Riverpod. I am wondering if it makes sense for this code to live inside of the bloc repository eventually. Tagging @felangel for his thoughts.
The text was updated successfully, but these errors were encountered: