[Discussion] Add Cubit Flutter Widgets?

[felangel]

Question

Do you like the current API in v6.0.0 of flutter_bloc where BlocBuilder, BlocListener, etc... are compatible with both blocs and cubits?

Current Usage

Blocs

// in most cases...
BlocBuilder<MyBloc, MyState>(...);

// in rare cases...
BlocBuilder<MyBloc, MyState>(
  cubit: myBloc,
  builder: (context, state) {...},
);

Cubits

// in most cases...
BlocBuilder<MyCubit, MyState>(...);

// in rare cases...
BlocBuilder<MyCubit, MyState>(
  cubit: myCubit,
  builder: (context, state) {...},
);

Introduce Cubit Flutter Widgets

Or would you prefer to have Cubit versions of each widget (CubitBuilder, CubitListener, etc...)?

Blocs

// in most cases...
BlocBuilder<MyBloc, MyState>(...);

// in rare cases...
BlocBuilder<MyBloc, MyState>(
  bloc: myBloc,
  builder: (context, state) {...},
);

Cubits

// in most cases...
CubitBuilder<MyCubit, MyState>(...);

// in rare cases...
CubitBuilder<MyCubit, MyState>(
  cubit: myCubit,
  builder: (context, state) {...},
);

Please give this issue a 👍 if you would prefer to have Cubit versions of all flutter_bloc widgets in v7.0.0 of flutter_bloc.

Please give this issue a 👎 if you would prefer to keep things as is and have one set of widgets that works with both blocs and cubits.

If you have an alternative proposal feel free to leave a comment 😄

Additional Context

• Draft PR feat(flutter_bloc): add cubit widgets #1559

[jeroen-meijer]

The associated PR (#1559) has been undrafted and is ready for review/consideration. 😄

Please vote thumbs up/down on the to let everyone know how you'd feel about these changes.

[zepfietje]

I think we should consider renaming cubit to something more similar to bloc. Maybe what we currently know as a cubit, should become a bloc, and the more powerful bloc (currently named bloc) should be renamed to something else.

Someone in the community has suggested EventBloc. I don't really like that name to be honest, but haven't been able to come up with a better suggestion yet.

Overall, this change feels like the better direction to me instead of fully splitting bloc and cubit again.
It's just an idea, so let me know what you think about this proposal, or if you have any naming suggestions.

[m-vellinga]

Just dumping some thoughts here as I was thinking (for a good while) about a thumbsup or thumbsdown.

I have the feeling the current naming can add something to the learning curve. With the current implementation you need to be aware of the "internals" that Bloc extends Cubit to fully understand the BlocBuilder etc classes and their public interfaces. As an example I can quite easily relate because of naming that "SportsCar" is a "Car" but not that a "Bloc" is a "Cubit".

Just to add an alternative idea. Since we are talking about the bloc package that facilitates the bloc architecture it makes sense to me that (just like the car analogy) Bloc would be the base class and classes that implement different ways to achieve that extend that class. That way having BlocBuilders etc with a bloc argument make for a consistent public interface.

[Jomik]

I do not like the idea of having these extra Cubit versions. It gives a larger surface. Makes it harder to maintain and document properly.
I would prefer if the BlocBuilder's cubit property was named bloc though, as it is more inline with the name of the component.
I guess, in my mind, I am thinking as Cubit as a slimmed down version of Bloc, rather than Bloc as an extension of Cubit.

[hawkinsjb1]

Is using a different named param (cubit: rather than bloc:) technically required for the package? If it is not then I would agree with @Jomik that having bloc: param work for both cases is the easiest on developers. The Builder/Listener widgets seem to do the exact same thing as far as the developer experience is concerned regardless of using a cubit or bloc implementation. So it begs the question of whether or not the widget tree NEEDS to know if its a cubit/bloc, and if it doesn't then having the bloc: param be interchangeable makes it more modular and easier to swap implementations later.

[jorgecoca]

Given the feedback observed on this thread, the community does not seem to have a clear consensus. My recommendation in that case would be to continue with the existing convention and wait to see if a better naming strategy surfaces, something that clearly resonates with a big majority.
While we can agree that the existing solution feels like it could be improved, none of the alternatives presented seem to improve (that much) what we already have.

[CurrySenpai]

Hello, check #1570

[felangel]

@CurrySenpai replied and closed in favor of keeping this discussion in one place.

[felangel]

@zepfietje see #1570 (comment) for why I would prefer not to rename Cubit to Bloc

[zepfietje]

@zepfietje see #1570 (comment) for why I would prefer not to rename Cubit to Bloc

@felangel, I understand your second point in that comment. However, for that same reason it's kind of strange to have widgets like BlocBuilder take either a cubit or bloc (using a parameter named after only one of those).

If we'd like to be 100% consistent, I'd suggest one of the following. Either merging them as I suggested in my previous comment, despite the technical differences. Or fully separating them as the original issue description suggested. Still open for any other solutions though.

[orsenkucher]

I don't feel there is a need to change the Bloc name to something else (especially EventBloc😆)
But what can be done, is inversion of notion, that is what @Jomik suggested in #1560 (comment)
Just treating Bloc and Cubit as interchangeable entities, regardless of internals,
And despite Cubit being broader abstraction, prefer to use Bloc as main concept

[omidraha]

Are there any similarities or understandings between bloc project and this riverpod project (that is successor of provider)?

Will both eventually move towards solving a fundamental problem?
Isn't it better to have a common path between the two?
To multiply the energy and like-mindedness for an optimal and specific package?

When I migrated from provider to bloc , I saw many syntax alike. (As it depends on that as package dependency.)
And now I think there are some concepts of cubit in river_pod.

[felangel]

@omidraha provider/riverpod are used to make objects available throughout a Flutter application. Bloc currently uses provider internally for BlocProvider, RepositoryProvider, etc... but if riverpod becomes the new standard and it makes sense then we will definitely consider updating the flutter_bloc package to align with riverpod instead. See kranfix/riverbloc#11 for more thoughts on this topic.

[felangel]

Closing this for now since the majority of the feedback was in favor of keeping the API as is (or even potentially reverting back to using bloc rather than cubit).