Should certain types be renamed? BlocXXX -> CubitXXX

[wujek-srujek]

I have been looking through the code of the latest version and I noticed the Cubit type has become more prominent. For example, BlocBuilder first type parameter is actually a Cubit (as it is the root of the hierarchy and BLoCs are Cubits). Shouldn't it be renamed to CubitBuilder, then? Right now I need to use a BlocBuilder even if I don't have a single BLoC in my codebase because I have Cubits. This question also pertains to many other types, like BlocConsumer, BlocListener, BlocWidgetBuilder and BlocBuilderCondition typedefs etc. I understand it would be a rather big undertaking resulting in a multitude of renamings and backwards-incompatible code...

[felangel]

Hi @wujek-srujek 👋
Thanks for opening an issue!

This is a duplicate of #1560. TL;DR adding Cubit widgets increases the API surface area without providing significant benefits and most of the feedback on the original issue was in favor of leaving the naming as is (or even using bloc for everything) in order to keep a simple/small API surface.

Hope that helps!

Closing for now since this is a duplicate but feel free to add additional comments and I'm happy to continue the conversation 👍

[wujek-srujek]

I wasn't asking if you should add Cubit widgets, but rather rename the existing ones starting with Bloc to start with Cubit, because this would be correct, and the current state of affairs isn't. For example, it just doesn't sound right to say you use a BlocBuilder with a Cubit instance which is not a Bloc, but it is always correct to say you use a CubitBuilder with an instance of a Cubit which is not a Bloc, or Bloc (as each bloc is a cubit, but not each cubit is a bloc).

To be honest, I personally find the decision to merge Cubit into the BLoC library and make it so prominent kind of strange as it is feels half-ready. The fact that I now have BlocBuilder(cubit: MyCubit(), ... seems pretty weird if MyCubit is not a Bloc - why is the widget called `BlocBuilder although there is no BLoC in sight?

It's also kind of strange to read the documentation of Cubit and see that it is a subset of Bloc; it feels reverted, the docs for Bloc should say it is a superset of Cubit. I mean, it is unusual to read the docs for a superclass that it is a simplification of its subclass, normally it would be the other way round. Imagine reading in Widget that it is a simplification of Text (I know, I know, Widget has multiple subclasses whereas Cubit only has one, for now, but what if it gets another one which will be a sibling of Bloc?).

Sorry for the criticism, but the latest versions of the library with the cubit parameter names (to me) lost the appeal of being simple, somehow it became inconsistent. In #1560 someone suggested renaming Cubit. For example, if:

• there were a common Bloc superclass
• and current Cubit were a subclass whose name were e.g. MethodBloc
• and current Bloc were another subclass (direct or indirect by extending Cubit) and it's name were e.g. EventBloc
• and the cubit parameters from BlocBuilder et. al. were renamed back to bloc

everything would be a Bloc (see what I did here? ;>) of some kind and there would be no issue with BlocBuilder etc. naming as it would be consistent. But I guess it could be too late for this to happen?

[wujek-srujek]

BTW, where does the name 'cubit' come from, what does it mean?

[felangel]

@wujek-srujek this decision was made because if we wanted to be really strict then the entire flutter_bloc package should also be renamed to flutter_cubit. This is how it originally started but led to felangel/cubit#69 because there was a lot of duplicated effort and maintenance cost. It would be an extremely disruptive change just for the sake of naming. The usage of BlocBuilder with an explicit cubit parameter is pretty rare and I'm still debating just renaming it back to bloc so that everything is bloc-based 👍

BlocBuilder(
  bloc: CounterCubit(),
  builder: (context, state) {...},
)

This way the "bloc" is referring to the package prefix and provides a consistent developer experience. Is that something you feel would improve your experience?

The trouble with calling the current Cubit class a Bloc and renaming the current Bloc to something like EventBloc is that technically Cubit isn't a Bloc because there is no event Sink.

Regarding the naming, cubit was selected because a cube is "block-like" and a bit implies a very small unit (since a cubit is a slimmed down version of bloc).

Would love to hear your thoughts and sorry for any inconvenience/confusion! I hope I communicated the rationale behind the current API and why it wasn't an easy decision to make.