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! 🙏

This issue is to track the work above as originally posted in felangel/cubit#69.