[PROPOSAL] Merge Cubit into Bloc

[felangel]

Hello everyone! 👋

First of all, thanks so much for the amazing support and enthusiasm! The interest and excitement surrounding cubit has been incredible 🙏 💙

Before diving into the proposal, I think it's valuable to provide some context around how cubit came about...

Context

It was brought to my attention several weeks ago that bloc was being used in a different way by various members of the community. Rather than adding events to the bloc, many developers found it simpler to just invoke methods on the bloc in which new states could be added.

class MyBloc extends Bloc<MyState, MyState> {
  MyBloc(): super(MyState.initial());

  @override
  Stream<State> mapEventToState(MyState state) async* {
    yield state;
  }

  void someAction() {
    final nextState = _getNextState();
    add(nextState);
  }
}

This approach, while different from the intended usage, raised some completely valid points:

• Not all state needs/benefits from being event-driven
• An event-driven approach introduces extra complexity (especially for new developers)
• An event-driven approach introduces additional code

After many invaluable discussions with many members of the Flutter community, we began experimenting with the idea of pulling events out of bloc and creating a slimmed down version called cubit. Needless to say, what started out as an experiment quickly grew (way quicker than I had imagined 😅).

I've been thinking about what the future could look like for both cubit and bloc and I have come to the conclusion that interoperability between the two would be a big win. Since cubit is a subset of bloc, most of the existing ecosystem can be shared (bloc_test, flutter_bloc, angular_bloc, hydrated_bloc, etc...). We have gone through the exercise of refactoring the existing ecosystem to use cubit as the base (cubit_test, flutter_cubit, angular_cubit, hydrated_cubit, etc...) which brings me to the proposal (drum roll please)

🥁 🥁 🥁 🥁 🥁 🥁 🥁 🥁 🥁 🥁 🥁 🥁

Proposal

🎉 I'm proposing to merge cubit into bloc 🎉

Justification

1. I think most would agree that there isn't a single best way to manage state; different types of state benefit from different state management solutions. Take for example autocomplete (or some sort of real-time search functionality) -- there is a significant benefit to taking an event-driven approach because it will likely be critical to debounce keypress events in order to avoid making excessive network requests. In the same application, we might have another feature which queries user profile data and presents it in the form of a profile page. In this case, the benefit of having an event-driven approach might not be as significant and to many it might be simpler to think of that interaction as a command/method (LoadUserProfile) rather than an event (UserProfileRequested).

2. Since cubit is a subset of bloc, the two are closely related and merging them would streamline the development and delivery process a lot. Features and fixes for cubit will almost always impact bloc so with the proposed structure we can iterate faster and ensure a higher level of quality across the entire ecosystem.

3. Unifying the two would provide a better developer experience. Rather than having to import cubit, flutter_cubit, cubit_test, bloc, flutter_bloc, and bloc_test, the developer experience could be improved by shipping cubit as part of bloc and ensuring compatibility across the entire existing bloc ecosystem. This would mean cubits and blocs could be consumed in the UI using existing widgets like BlocBuilder, BlocListener, BlocProvider, etc... which many developers are already familiar with. There would not be a need to use CubitBuilder and BlocBuilder (when in reality their implementations are identical). Cubits and blocs could also be unit tested using the existing blocTest package.

4. Maintaining the ecosystem would be greatly simplified because packages like hydrated_cubit could be used as mixins and be made compatible with both the Cubit and Bloc classes. In addition, the documentation at bloclibrary.dev could be updated to include an introduction to cubit, lead into bloc and showcase real-world examples of when to use one vs the other.

5. Current and future tooling could be consolidated/reused. Rather than maintaining separate tooling for generating/using blocs and cubits we could unify things under the current bloc tooling environment and continue to iterate and improve upon the existing infrastructure.

6. We can continue to maintain a single (awesome) community of developers via the bloc discord and github repository and have all of the resources readily available and easily accessible to both new and experienced developers.

Consequences

The consequences of these changes would be:

• The cubit package would be deprecated and the cubit github repository would be archived.
• The current cubit code would be moved into the bloc package (under the bloc github repository).
• The bloc package would export cubit and bloc.
• The flutter_bloc package would be made compatible with both bloc and cubit instances
• The bloc_test package would be made compatible with both bloc and cubit instances
• The angular_bloc package would be made compatible with both bloc and cubit instances
• The hydrated_bloc code would be moved into the bloc github repository and the current repository would be archived.
• The hydrated_bloc package would be made compatible with both bloc and cubit instances.
• The replay_cubit package would be deprecated and migrated into the replay_bloc package (WIP).

I'm anticipating there will be breaking changes so this would likely all be within the scope of the v6.0.0 release of bloc.

If there are no major objections to this proposal, we will work as hard as we can to deliver these changes as soon as possible while ensuring a high level of quality.

Please give this issue a 👍 if you support the proposal or a 👎 if you're against it. If you object to the proposal I would really appreciate it if you could comment with your reasoning.

Thanks so much for all of the continued support and looking forward to hearing everyone's thoughts on the proposal! 🙏

[YeungKC]

It should be done, it looks very good

[NotHolst]

Agreed, this is a good solution!

[gitboss]

Agreed

[rodydavis]

I think it is a wonderful idea 😎

[farellsujanto]

Cool!

[mhadaily]

it seems like a fantastic idea!

[albertodev01]

This is a good idea! Having 2 different packages also looks like cubit and bloc are 2 different things (even if it's clearly stated in the README that they aren't) and people may get confused

[Ferdzzzzzzzz]

I've been using Cubit for a week and already ran into a couple of scenarios where I thought about this, please proceed 👍

[anisalibegic]

Go for it!

[vinceramcesoliveros]

👍 Can't wait to migrate my extra-boilerplate event code into just methods. 😄

[Mastersam07]

This is a good one. It should be done 👍

[tomialagbe]

Great idea!

[Botanium]

Go for it. Putting all resources in one package saves a lot of time and effort.

[saddemYassin]

I think it's great to make them together. In the end they are complementary. So go for it.

[Aanu1995]

Thank you for all you do for the community. I love the idea

[irvine5k]

I love the idea. Cubit is a great feature for sure and a uniaue documentation will be the best advantage IMHO.

[koiralapankaj7]

Agreed!

[iampato]

no its not

[orsenkucher]

Ой-ой, some rly hot fusion is taking place😻😱🤯🥰😎

[aissat]

Yeah that's cool

[orsenkucher]

• We'll probably have to archive old repositories only after v6.0.0 is released, but let's start moving straight away and make felangel/bloc:development branch🚀🚀
• This is also possible to maintain all commit history of retired repositories!
• And one more thing to consider is a creation of Bloc organisation to have a nice Verified badge for bloclibrary.dev😂😝

@felangel

[Gene-Dana]

In terms of maintenance and updates I think this makes alot of sense - the benefits far outweigh the costs. The biggest concern is to make sure that your examples are all encompassing and clear, which you guys already excel at ! I'm excited to see it get better!

[aosorio-avilez]

I completely agree 😬

[bruntzcreative]

unpopular opinion I think having them as seperate packages is a better way to go. As you said the motivation for Cubits creation is the unintended method of use by developers using bloc. It makes sense that many people will simply prefer Cubit over bloc.

[felangel]

@bruntzcreative thanks for the feedback! Can you provide a bit more context? With the current proposal, developers can definitely decide to only use cubit and would still benefit from having a unified ecosystem and the option to "upgrade" their cubits to blocs seamlessly. Thoughts?

[bruntzcreative]

@felangel Having them in same package could be confusing and deter from Cubit. On its own Cubit is a simple straight forward way to manage state much like people roll their own with provider. Bloc is quite cumbersome and difficult for newer devs to understand why it is what it is, combined with bloc Cubit could be blurred and obfuscated to many who would otherwise use it. I understand your motivation to merge the two and it is perfectly valid. It would be a shame to see Cubit take a backseat to bloc. Cubit seems like the perfect gateway to bloc.

[felangel]

@bruntzcreative that's super helpful feedback. Do you think your concerns would be alleviated with improvements to the documentation, examples/tutorials, and tooling? This proposal would treat cubit as a first class citizen in the bloc library. I would hate for cubit to be hidden or obfuscated by moving it into bloc and actually hope that by moving it into bloc it would gain more visibility/exposure.

[bruntzcreative]

@felangel Giving Cubit its own arm like bloc has would definitely changes my thoughts on merging the two. Framing Cubit in a manner that shows it as a simple easy to use entry point would also make bloc more accessible to newer devs. You've convinced me!

[tapizquent]

Having the benefits of both sounds like a great win to me. Go right ahead! 👍

[bizz84]

Makes perfect sense. Easier to import, less overhead. I like to think of them as the lightweight and heavyweight version of the same library.

[pblinux]

I totally agree, I just started to use Cubit and for my surprise, there's no RepositoryProvider. 😅 I think it would be good for new devs to have an unique starting point for both bloc and cubit. 😄

[felangel]

Due to the overwhelming support we're moving ahead with this proposal! 🚀
Follow along at felangel/bloc#1427 🎉