Bloc: Question: Cubit vs Bloc

[Peng-Qian]

Hi @felangel ,

So excited the cubit out, the method-driven feature is really awesome.

I have some questions about the cubit, could you please explain more about the purpose to create cubit, and what is the key difference/Strength compared to the bloc?

1. is cubit just designed to offer the syntax sugar or reduce the code size/complexity?
2. does cubit be capable to do all things that bloc can do? (based on my current understanding and usage, I think it does. But I am not so sure.)
3. could you give some suggestions/scenarios that should apply cubit rather than bloc?
4. If the cubit is functionally the same to the bloc and just optimized/simplified structure of bloc, will this be a trend of bloc further development? (should we more prefer to use cubit rather than bloc since it is a kind of evolve of bloc)

[felangel]

Hi @Peng-Qian 👋
Thanks for opening an issue!

1. Cubit is a subset of Bloc so it reduces complexity but you also lose some functionality.
2. No, since Cubit has no notion of events, things like debounce, switchMap, throttle, etc... will not be as easy to support with Cubit and you'd be better off using Bloc.
3. I will cover this in the upcoming documentation updates so stay tuned 😄 but if you're not sure you can start with Cubit and convert your Cubit to Bloc as needed in v6.0.0.
4. Like I mentioned, Cubit is a subset of Bloc (Bloc extends Cubit) so you can think of Cubit as a simplified Bloc which has less functionality. Blocs are more powerful than Cubits but Cubits are more simple.

Like I said all of these questions will be covered in great detail once v6.0.0 is out so stay tuned 👍

[Peng-Qian]

Thanks for your explanations!~ @felangel 👍

[HerrNiklasRaab]

@felangel Hey, could you make a small example, how Cubit makes for example debounce impossible. Didn't got that one.

PS: Thanks for this amazing package so far!

[narcodico]

@HerrNiklasRaab cubit doesn't make debounce impossible, but you'd have to implement a mechanism for your methods to be debounced. As for with bloc, this is really easy to achieve.

[HerrNiklasRaab]

Got it thanks!

[dave]

Another thing I've found hard with my cubit app is a UI to allow a generic error message to include a "retry" button. It's my first flutter app, so I haven't used bloc before, but I would imagine with bloc I could just include the original event in the "error" state, and the view can just resubmit it. With cubit it's a little more complex.

[HerrNiklasRaab]

Could you make a small example?

[dave]

I can explain a bit further. I'm trying to make my app "offline first" so every UI operation that requires an active internet connection has a popup when the connection is offline, like this:

This popup is identical on a multitude of UI elements so I made a helper function that lives in the view layer - here's an example of calling it.

I also have generic functionality for error handling (that shows a popup with appropriate buttons), so I made a helper function for this too:

... this way, the cubit is relieved of all error handling duties and all the cubit's methods have to do is throw exceptions. These are caught by the helper function in the view layer and appropriate UI is shown.

I'm coming to the conclusion that this is logic is perhaps too complex to live in the view layer, and it should really live in my cubits. I've been thinking about how to migrate this to the cubit layer without enormous complexity and repeated code in every cubit method. The "try anyway" and "retry" buttons are the difficult bit.

Here's the app deployed to the web. Log in with email "a" and code "a". (Click the cloud at the top and click "go offline" to simulate being offline). The item named "broken-item" will throw an error when downloaded.

[HerrNiklasRaab]

I understand, but this complex no matter if you choose Cubit or Bloc. Did you have any impediments implementing this only with Cubits for example?