Question 1

What is the BLoC pattern and how does it work?

Accepted Answer

BLoC is a stream-based model separating business logic from the UI: the UI dispatches an event, the BLoC processes it and emits a new state, and the UI is rebuilt from that state. State changes only inside the BLoC via emit, and that one-way flow is what makes behaviour predictable. Cover both forms: Cubit (methods, no events) and Bloc (event classes plus handlers). Finish with the practical payoff: a BLoC is a plain Dart class, so it unit-tests without a widget tree, and a BlocObserver logs every transition from one place.

Question 2

Cubit or Bloc — how do you choose?

Accepted Answer

My default is Cubit, because it gives the same separation with far less boilerplate — no event classes, no handlers. I move to Bloc in three cases: (1) I need an event history for auditing, analytics or a record of what the user did; (2) I need control over the event stream — debouncing a search field, sequencing rapid events, which transformer provides out of the box; (3) a large team benefits from the enforced structure. So the choice rests on a concrete need, not on popularity.

Question 3

How do you test a BLoC?

Accepted Answer

Because a BLoC is a plain Dart class the test is straightforward: substitute the repository with a fake, dispatch an event (or call the Cubit method) and assert on the sequence of emitted states. The bloc_test package gives that a ready structure with build, act and expect sections. What I assert is concrete: [Loading, Ready] on success, [Loading, Failed] on error. One detail matters: assert the sequence, not just the final state — skipping the Loading state is a real UX bug and only a sequence assertion catches it.

Question 4

How do you model your state class?

Accepted Answer

Two approaches. A sealed hierarchy — Loading, Ready, Failed as separate classes: impossible combinations like loading-and-error cannot be expressed, and Dart's exhaustive switch forces every case to be handled. A single class with fields — isLoading, data, error together: less code, but it permits invalid states. The answer expected at middle level: I use a sealed hierarchy on non-trivial screens, because a forgotten error state is the most common bug and the type system catches it at compile time.

Criterion	Cubit	Bloc
Amount of boilerplate	Low — just methods	Higher — event classes plus handlers
Event history	No	Yes — every event is traceable
Event stream control (debounce, throttle)	Manual	Built in via `transformer`
When to choose	Simple to moderate state	Audit trails, complex flows, large teams

BLoC and Cubit

📚 Sources and documentation