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
-
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
).
-
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.
-
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.
-
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.
-
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.
-
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! π
help wanted feedback wanted