0Pricing
Flutter Mobile Development · Lektion

Events, Zustände und die Entscheidung zwischen Cubit und Bloc

Entscheiden Sie zwischen Cubit und Bloc und entwerfen Sie klare Transformationen von Events in Zustände.

Events, Zustände und die Entscheidung zwischen Cubit und Bloc ist eine kostenlose Flutter Mobile Development-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Flutter Mobile Development-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Flutter Mobile Development-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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.

Häufig gestellte Fragen

Ist die Lektion „Events, Zustände und die Entscheidung zwischen Cubit und Bloc“ kostenlos?

Ja — der vollständige Text von „Events, Zustände und die Entscheidung zwischen Cubit und Bloc“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Flutter Mobile Development-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Flutter Mobile Development-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Events, Zustände und die Entscheidung zwischen Cubit und Bloc“?

Entscheiden Sie zwischen Cubit und Bloc und entwerfen Sie klare Transformationen von Events in Zustände. Du übst Flutter Mobile Development mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Flutter Mobile Development zu starten?

Keine Vorkenntnisse erforderlich. Flutter Mobile Development auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Events, Zustände und die Entscheidung zwischen Cubit und Bloc“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Flutter Mobile Development-Lektion Code schreiben und ausführen?

Ja. Jede Flutter Mobile Development-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Events, Zustände und die Entscheidung zwischen Cubit und Bloc
  2. Stream-Transformer und Event-Debouncing in BLoC
  3. Zustand mit HydratedBloc persistieren
  4. BLoCs mit bloc_test und Mocktail testen
← Zurück zu Flutter Mobile Development