0Pricing
Flutter Mobile Development · Lesson

Events, States, and the Cubit-vs-Bloc Decision

Decide between Cubit and Bloc and design clean event-to-state transformations.

Events, States, and the Cubit-vs-Bloc Decision is a free Flutter Mobile Development lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Flutter Mobile Development learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Two Tools, One Family

The flutter_bloc package ships two state-management primitives: Cubit and Bloc. Both extend the same base class and both emit a stream of states to your UI.

  • Cubit exposes plain methods you call directly (e.g. increment()).
  • Bloc reacts to events you add (e.g. add(IncrementPressed())) and maps them to states.

This lesson teaches you how each one transforms input into State, and how to pick the right one for a given feature.

Cubit: Methods to States

A Cubit is the simpler primitive. You extend Cubit<T>, pass an initial state to super(...), and call emit(newState) inside methods to push a new state to listeners.

There is no event object and no mapping layer. The method is the API surface.

import 'package:flutter_bloc/flutter_bloc.dart';

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);

  void increment() => emit(state + 1);
  void decrement() => emit(state - 1);
  void reset() => emit(0);
}

Bloc: Events to States

A Bloc separates the intent (an event) from the logic (a handler). You define event classes, then register handlers with on<Event> in the constructor. The UI never calls logic directly; it only adds events.

This indirection costs more boilerplate but gives you a single, traceable funnel for every state change.

import 'package:flutter_bloc/flutter_bloc.dart';

sealed class CounterEvent {}

class IncrementPressed extends CounterEvent {}
class DecrementPressed extends CounterEvent {}

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<IncrementPressed>((event, emit) => emit(state + 1));
    on<DecrementPressed>((event, emit) => emit(state - 1));
  }
}

Modeling States Explicitly

A plain int works for a counter, but real features have multiple shapes: loading, success, failure. Model these as a sealed class hierarchy so the compiler forces your UI to handle every case.

  • Sealed classes enable exhaustive switch in Dart 3.
  • Each state carries only the data valid for that phase.
sealed class ProfileState {
  const ProfileState();
}

class ProfileLoading extends ProfileState {
  const ProfileLoading();
}

class ProfileLoaded extends ProfileState {
  final String name;
  const ProfileLoaded(this.name);
}

class ProfileError extends ProfileState {
  final String message;
  const ProfileError(this.message);
}

void main() {
  final ProfileState s = ProfileLoaded('Ada');
  final label = switch (s) {
    ProfileLoading() => 'Loading...',
    ProfileLoaded(:final name) => 'Hello, $name',
    ProfileError(:final message) => 'Error: $message',
  };
  print(label);
}

Equatable: Avoiding Redundant Rebuilds

Bloc and Cubit only notify listeners when the new state is not equal to the previous one. By default Dart objects compare by identity, so two distinct instances with the same data are treated as different and trigger a rebuild.

Override equality (commonly with the equatable package) so value-equal states are deduplicated and your widgets stop rebuilding needlessly.

import 'package:equatable/equatable.dart';

class CartState extends Equatable {
  final int itemCount;
  final double total;
  const CartState(this.itemCount, this.total);

  @override
  List<Object?> get props => [itemCount, total];
}

// emit(CartState(2, 19.98)) twice in a row notifies listeners only once.

Async Work Inside a Handler

Most real handlers are asynchronous: fetch data, then emit. With a Bloc you can emit multiple times from one handler — first a loading state, then success or failure.

The handler signature gives you an emit callback rather than a return value precisely so you can stream several states during one event.

class ProfileBloc extends Bloc<ProfileEvent, ProfileState> {
  final ProfileRepo repo;
  ProfileBloc(this.repo) : super(const ProfileLoading()) {
    on<ProfileRequested>((event, emit) async {
      emit(const ProfileLoading());
      try {
        final name = await repo.fetchName(event.id);
        emit(ProfileLoaded(name));
      } catch (e) {
        emit(ProfileError(e.toString()));
      }
    });
  }
}

Event Transformers: The Bloc-Only Superpower

This is the feature that most often decides the question. With a Bloc you control how concurrent events are processed by passing a transformer to on<Event> (from the bloc_concurrency package):

  • concurrent() — handle all events in parallel (default).
  • sequential() — one at a time, in order.
  • droppable() — ignore new events while one is running (great for buttons).
  • restartable() — cancel the in-flight handler when a newer event arrives (great for search).

Cubit has no event stream, so it cannot do this without writing the debounce/throttle logic by hand.

import 'package:bloc_concurrency/bloc_concurrency.dart';
import 'package:stream_transform/stream_transform.dart';

EventTransformer<E> debounce<E>(Duration d) {
  return (events, mapper) => events.debounce(d).switchMap(mapper);
}

class SearchBloc extends Bloc<SearchEvent, SearchState> {
  SearchBloc() : super(const SearchInitial()) {
    on<QueryChanged>(
      _onQueryChanged,
      transformer: debounce(const Duration(milliseconds: 300)),
    );
  }

  Future<void> _onQueryChanged(QueryChanged e, Emitter emit) async {
    // runs at most once per 300ms of typing
  }
}

Observing Transitions for Debugging

Because a Bloc funnels every change through events, it can report a full Transition: the current state, the triggering event, and the next state. Override onTransition (or use a global BlocObserver) to log this funnel.

A Cubit only sees Change (current and next state) — there is no event to log, because there is no event. This is why Bloc is favored for features that need an audit trail.

import 'package:flutter_bloc/flutter_bloc.dart';

class AppObserver extends BlocObserver {
  @override
  void onTransition(Bloc bloc, Transition transition) {
    super.onTransition(bloc, transition);
    print('${bloc.runtimeType}: ${transition.event} '
        '=> ${transition.nextState}');
  }
}

void main() {
  Bloc.observer = AppObserver();
}

The Decision Rule

A practical heuristic the Bloc maintainers themselves recommend: start with a Cubit and reach for a Bloc only when you need what a Bloc adds.

Choose Cubit when:

  • The logic is simple direct method calls (toggles, counters, form fields).
  • You do not need to debounce/throttle/drop concurrent inputs.
  • You value less boilerplate and easier onboarding.

Choose Bloc when:

  • You need event transformers (debounce search, droppable submit).
  • You want a traceable event log for analytics or debugging.
  • Many distinct inputs map to one feature and you want them documented as event types.

Same Feature, Both Ways

Compare a toggle written as a Cubit versus a Bloc. The Cubit is shorter and reads top-to-bottom; the Bloc adds an event type and a handler. For a pure toggle, the Cubit is the better choice — the Bloc machinery buys you nothing here.

// Cubit version
class ThemeCubit extends Cubit<bool> {
  ThemeCubit() : super(false);
  void toggle() => emit(!state);
}

// Bloc version (same behavior, more ceremony)
sealed class ThemeEvent {}
class ThemeToggled extends ThemeEvent {}

class ThemeBloc extends Bloc<ThemeEvent, bool> {
  ThemeBloc() : super(false) {
    on<ThemeToggled>((e, emit) => emit(!state));
  }
}

Designing Clean Event-to-State Transformations

Whichever you pick, keep transformations clean:

  • States are immutable; use copyWith to derive the next state instead of mutating.
  • One event (or method) should map to a coherent set of emitted states, never to UI navigation or side effects you cannot trace.
  • Keep I/O in a repository; the Bloc/Cubit only orchestrates and emits.
class FormState {
  final String email;
  final bool submitting;
  const FormState({this.email = '', this.submitting = false});

  FormState copyWith({String? email, bool? submitting}) => FormState(
        email: email ?? this.email,
        submitting: submitting ?? this.submitting,
      );
}

void main() {
  const start = FormState();
  final next = start.copyWith(submitting: true);
  print('${next.email}|${next.submitting}'); // |true
}

Quick Check

A search field must issue a network request as the user types, but only after they pause for 300ms, cancelling any in-flight request when a newer keystroke arrives. Which choice best fits and why?

Recap

You learned how each primitive turns input into state and how to choose:

  • Cubit = methods call emit directly. Less boilerplate; ideal for toggles, counters, and simple forms.
  • Bloc = events are added and mapped via on<Event>. Buys you event transformers (debounce/throttle/droppable/restartable) and a traceable Transition log.
  • Model states as sealed, immutable classes; use Equatable to dedupe rebuilds and copyWith to derive next states.
  • Rule of thumb: start with a Cubit; upgrade to a Bloc only when you need concurrency control or an event audit trail.

Frequently asked questions

Is the “Events, States, and the Cubit-vs-Bloc Decision” lesson free?

Yes — the full text of “Events, States, and the Cubit-vs-Bloc Decision” is free to read here on the web, and the Flutter Mobile Development course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Flutter Mobile Development course, upgrade to CoddyKit PRO.

What will I learn in “Events, States, and the Cubit-vs-Bloc Decision”?

Decide between Cubit and Bloc and design clean event-to-state transformations. You practise Flutter Mobile Development with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Flutter Mobile Development?

No prior experience is required. Flutter Mobile Development on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Events, States, and the Cubit-vs-Bloc Decision” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Flutter Mobile Development lesson?

Yes. Every Flutter Mobile Development lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Events, States, and the Cubit-vs-Bloc Decision
  2. Stream Transformers and Event Debouncing in BLoC
  3. Persisting State with HydratedBloc
  4. Testing BLoCs with bloc_test and Mocktail
← Back to Flutter Mobile Development