BLoC & Patterns

One direction, always

BLoC (Business Logic Component) is a pattern built on a strict rule: data flows in one direction. The UI sends events (or method calls) in; the BLoC emits states out; the UI rebuilds from those states. The UI never mutates state directly, and business logic never touches widgets.

sequenceDiagram
  participant UI
  participant Bloc
  UI->>Bloc: add(Event) / method call
  Bloc->>Bloc: run business logic
  Bloc->>UI: emit(new State)
  UI->>UI: rebuild from State

Unidirectional data flow

This one-way discipline is the whole value. Because state only ever changes in one place, in response to explicit inputs, the app becomes predictable and testable — you can feed events to a BLoC in a test and assert the exact sequence of states, with no widgets involved.

Cubit: the simpler half

The BLoC library ships two flavors. Cubit is the simpler one — no event classes, you just call methods that emit new states. Start here.

// State flows out; methods are the inputs.
class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);          // initial state

  void increment() => emit(state + 1); // emit a new state
  void reset() => emit(0);
}

// In the UI: BlocBuilder rebuilds when a new state is emitted.
BlocBuilder<CounterCubit, int>(
  builder: (context, count) => Text('$count'),
);

// Trigger an input:
context.read<CounterCubit>().increment();

BLoC proper adds explicit Event classes between the UI and the logic (add(IncrementPressed()) instead of increment()). That indirection buys you a documented, loggable list of every possible input — valuable in large apps, overkill in small ones.

When the ceremony pays off

BLoC is more structure than setState or Provider, and that structure is a cost you pay upfront. It earns back when:

The app is large and you want business logic in testable units, fully separate from UI.
State transitions are complex — many events, async flows, and you want them explicit and traceable.
A team benefits from one enforced pattern across the codebase.

For a small app or a single screen’s local state, BLoC is over-engineering — setState or a simple ChangeNotifier is clearer. The skill is matching the ceremony to the complexity.