Implementing Cubit: A Simpler Version of BLoC Using Functions That Emit States.

Implementing Cubit: A Simpler Version of BLoC Using Functions That Emit States – A Lecture for the Chronically Confused (and Everyone Else)

(Professor Armchair, Ph.D. (Probably), at the helm. Grab your coffee, settle in, and prepare to have your mind… mildly rearranged.)

Alright, class! Settle down, settle down! Today, we’re diving into the wonderful world of state management in Flutter. And no, I don’t mean the existential crisis you face when trying to decide which state to live in (California? Colorado? Denial?). We’re talking about managing the application state – the data that drives your UI and makes it tick.

We’re going to conquer the beast that is state management by tackling a simplified, elegant solution called Cubit. Think of Cubit as BLoC’s chill cousin. They’re both family, but Cubit prefers surfing 🏄‍♂️ and wearing flip-flops, while BLoC is more likely to be found in a boardroom, meticulously planning world domination.

(Disclaimer: BLoC is a powerful pattern and has its place. We’re just focusing on Cubit for its simplicity. No BLoCs were harmed in the making of this lecture.)

Lecture Outline:

1. The Agony of Unmanaged State (or, Why We Need Help) 😫
2. Introducing Cubit: Your Friendly Neighborhood State Manager 🦸
3. Key Concepts: State, Emitters, and the Cubit Class 🔑
4. Building a Simple Counter App with Cubit (The "Hello World" of State Management) ➕➖
5. Beyond the Basics: Handling Asynchronous Operations and Error States ⏳🔥
6. Cubit vs. BLoC: The Great Debate (Simplified) 🤔
7. Testing Your Cubit (Because Bugs Are the Enemy) 🐛
8. Best Practices and Common Pitfalls (Avoid the Potholes!) 🚧
9. Conclusion: Farewell, and May Your States Be Manageable! 👋

---

1. The Agony of Unmanaged State (or, Why We Need Help) 😫

Imagine building a house without a blueprint. Utter chaos, right? Bricks flying everywhere, walls collapsing… Your app’s state without proper management is pretty much the same thing.

Without a clear, structured way to manage your data, you’ll quickly descend into a spaghetti code nightmare. You’ll be passing data around like a hot potato 🥔, unsure where it came from or where it’s going. Debugging becomes a Herculean task, and your users will suffer the consequences (i.e., a buggy, unpredictable app).

Here’s a glimpse of the horrors of unmanaged state:

• Prop Drilling: Passing data down through multiple layers of widgets that don’t even need it. It’s like trying to deliver a pizza 🍕 by throwing it from the roof of one building to another. Messy and inefficient!
• Scattered State Updates: Making changes to the state from random places in your code. Think of it as trying to herd cats 🐈‍⬛🐈‍⬛🐈‍⬛. Impossible!
• Testing Nightmares: Trying to test components that are tightly coupled to the UI and have unpredictable state. Good luck with that! 🍀

The Solution? A structured state management solution! And that’s where our hero, Cubit, enters the scene.

2. Introducing Cubit: Your Friendly Neighborhood State Manager 🦸

Cubit is a lightweight, simple, and predictable state management library for Flutter. It’s designed to be easier to understand and use than BLoC, making it a great choice for smaller to medium-sized applications or for developers just starting out with state management.

Think of Cubit as a conductor of an orchestra 🎼. It doesn’t play the instruments itself, but it tells them when to play and what to play. In this analogy, the instruments are your UI components, and the "music" is the state of your application.

What makes Cubit so cool?

• Simplicity: It’s based on a single class with a straightforward API. No complicated event streams or transformers.
• Predictability: State transitions are explicit and predictable, making debugging easier.
• Testability: Cubits are easily testable, ensuring your app behaves as expected.
• Maintainability: Well-structured state management leads to cleaner, more maintainable code.

3. Key Concepts: State, Emitters, and the Cubit Class 🔑

Let’s break down the core concepts of Cubit:

• State: The data that represents the current condition of your application. It can be anything from a simple counter value to a complex object representing user data. State is immutable, meaning you don’t modify it directly. You create new states based on previous ones.

  • Example: In a counter app, the state might be just a single integer representing the current count: int count. In a user profile app, the state might be a User object containing the user’s name, email, and other details.
• Cubit: A class that holds the application’s state and provides methods to update it. It’s the heart of your state management logic. The Cubit extends the Cubit<State> class, where State is the type of state it manages.
• Emitter: A function (provided by the Cubit) that allows you to emit new states. This is how you update the UI. Think of it as a signal that tells the UI "Hey, the state has changed! Time to rebuild!". The emit() method is the magic wand 🪄 that triggers a state update.

Let’s put it in a table:

Concept	Description	Example
State	The data that represents the current condition of your application. Immutable.	int count (for a counter), User user (for a user profile)
Cubit	A class that holds the state and provides methods to update it. Extends Cubit<State>.	CounterCubit extends Cubit<int> (manages an integer state), UserCubit extends Cubit<User> (manages a User object as state)
Emitter	A function (emit()) provided by the Cubit that allows you to emit new states. Triggers UI updates.	emit(state + 1) (increments the counter and emits the new state), emit(user.copyWith(name: newName)) (creates a new User object)

4. Building a Simple Counter App with Cubit (The "Hello World" of State Management) ➕➖

Let’s build a classic counter app to illustrate the power of Cubit.

Step 1: Add the flutter_bloc Dependency

First, add the flutter_bloc dependency to your pubspec.yaml file:

dependencies:
  flutter:
    sdk: flutter
  flutter_bloc: ^8.1.3 # Use the latest version!

Run flutter pub get to install the dependency.

Step 2: Create the CounterCubit

Create a file named counter_cubit.dart:

import 'package:flutter_bloc/flutter_bloc.dart';

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0); // Initial state is 0

  void increment() => emit(state + 1);

  void decrement() => emit(state - 1);
}

Explanation:

• We extend Cubit<int> because our state is a simple integer representing the counter value.
• The CounterCubit() constructor initializes the state to 0.
• The increment() and decrement() methods are the actions that update the state. They use emit() to emit a new state based on the current state.

Step 3: Build the UI

Modify your main.dart file:

import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
import 'counter_cubit.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Counter App with Cubit',
      home: BlocProvider(
        create: (context) => CounterCubit(),
        child: CounterPage(),
      ),
    );
  }
}

class CounterPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Counter')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text('You have pushed the button this many times:'),
            BlocBuilder<CounterCubit, int>(
              builder: (context, state) {
                return Text(
                  '$state',
                  style: Theme.of(context).textTheme.headlineMedium,
                );
              },
            ),
            Row(
              mainAxisAlignment: MainAxisAlignment.center,
              children: [
                FloatingActionButton(
                  onPressed: () => context.read<CounterCubit>().increment(),
                  child: Icon(Icons.add),
                ),
                SizedBox(width: 16),
                FloatingActionButton(
                  onPressed: () => context.read<CounterCubit>().decrement(),
                  child: Icon(Icons.remove),
                ),
              ],
            ),
          ],
        ),
      ),
    );
  }
}

Explanation:

• We use BlocProvider to provide the CounterCubit to the CounterPage. This makes the Cubit accessible to the entire widget tree below.
• BlocBuilder is a widget that rebuilds whenever the state of the CounterCubit changes. It takes a builder function that receives the current context and the current state (the integer value in this case).
• We use context.read<CounterCubit>() to access the CounterCubit instance from the widget tree. This allows us to call the increment() and decrement() methods when the buttons are pressed.

Run your app! You should see a counter that increments and decrements when you press the buttons. Congratulations! You’ve built your first Cubit-powered app! 🎉

5. Beyond the Basics: Handling Asynchronous Operations and Error States ⏳🔥

Our counter app is simple, but real-world applications often involve asynchronous operations (like fetching data from an API) and handling potential errors.

Asynchronous Operations:

Let’s say we want to load the initial counter value from a remote server. We can do this with an asynchronous function:

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

  Future<void> _loadInitialValue() async {
    // Simulate fetching data from a remote server
    await Future.delayed(Duration(seconds: 2));
    emit(42); // Load the initial value (the answer to everything!)
  }

  void increment() => emit(state + 1);

  void decrement() => emit(state - 1);
}

Explanation:

• We call _loadInitialValue() in the constructor.
• _loadInitialValue() is an async function that simulates fetching data from a remote server using Future.delayed().
• After the delay, we emit the initial value (42 in this case).

Error States:

What happens if our asynchronous operation fails? We need to handle the error and update the UI accordingly. We can define a separate state for errors:

import 'package:flutter_bloc/flutter_bloc.dart';

enum CounterStateStatus { initial, loading, success, failure }

class CounterState {
  final int count;
  final CounterStateStatus status;
  final String? errorMessage;

  CounterState({
    required this.count,
    required this.status,
    this.errorMessage,
  });

  CounterState copyWith({
    int? count,
    CounterStateStatus? status,
    String? errorMessage,
  }) {
    return CounterState(
      count: count ?? this.count,
      status: status ?? this.status,
      errorMessage: errorMessage ?? this.errorMessage,
    );
  }
}

class CounterCubit extends Cubit<CounterState> {
  CounterCubit() : super(CounterState(count: 0, status: CounterStateStatus.initial)) {
    _loadInitialValue();
  }

  Future<void> _loadInitialValue() async {
    emit(state.copyWith(status: CounterStateStatus.loading));
    try {
      // Simulate fetching data from a remote server
      await Future.delayed(Duration(seconds: 2));
      emit(state.copyWith(count: 42, status: CounterStateStatus.success));
    } catch (e) {
      emit(state.copyWith(status: CounterStateStatus.failure, errorMessage: e.toString()));
    }
  }

  void increment() => emit(state.copyWith(count: state.count + 1));

  void decrement() => emit(state.copyWith(count: state.count - 1));
}

Explanation:

• We define an enum CounterStateStatus to represent the different states of our loading operation (initial, loading, success, failure).
• We create a CounterState class to hold both the counter value and the status.
• We use copyWith() to create new CounterState objects based on the previous one. This ensures immutability.
• In _loadInitialValue(), we emit a loading state before starting the asynchronous operation.
• We wrap the asynchronous operation in a try...catch block to handle potential errors.
• If an error occurs, we emit a failure state with an error message.

Update the UI to reflect the different states:

You’ll need to modify your BlocBuilder to handle the different states and display appropriate UI elements (e.g., a loading indicator, an error message).

6. Cubit vs. BLoC: The Great Debate (Simplified) 🤔

Cubit and BLoC are both state management solutions from the same family (Flutter Bloc). The main difference lies in how they handle state updates:

• Cubit: Uses simple functions that directly emit new states. It’s synchronous by default, but can handle asynchronous operations as shown above.
• BLoC: Uses events and streams to trigger state changes. It’s more complex but offers more flexibility for handling complex business logic.

Here’s a table summarizing the key differences:

Feature	Cubit	BLoC
Complexity	Simpler, easier to learn and use.	More complex, requires understanding of streams and events.
State Updates	Functions that directly emit new states.	Events trigger state changes through streams and transformers.
Asynchronous Ops	Handled within the Cubit methods.	Handled using event transformers and stream processing.
Boilerplate Code	Less boilerplate code.	More boilerplate code.
Use Cases	Smaller to medium-sized applications, simpler state management needs.	Larger, more complex applications with complex business logic requirements.

Which one should you choose?

• Start with Cubit: If you’re new to state management or building a smaller application, Cubit is a great choice. It’s easier to learn and use, and it provides a solid foundation for managing your app’s state.
• Graduate to BLoC: If your application becomes more complex and requires more sophisticated state management techniques, you can always migrate to BLoC later.

7. Testing Your Cubit (Because Bugs Are the Enemy) 🐛

Testing is crucial for ensuring your Cubit behaves as expected. Here’s how you can test your CounterCubit:

Step 1: Add the bloc_test Dependency

Add the bloc_test dependency to your dev_dependencies in pubspec.yaml:

dev_dependencies:
  flutter_test:
    sdk: flutter
  bloc_test: ^9.1.4 # Use the latest version!

Run flutter pub get.

Step 2: Write the Tests

Create a file named counter_cubit_test.dart in your test directory:

import 'package:bloc_test/bloc_test.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:your_app_name/counter_cubit.dart'; // Replace with your actual path

void main() {
  group('CounterCubit', () {
    late CounterCubit counterCubit;

    setUp(() {
      counterCubit = CounterCubit();
    });

    tearDown(() {
      counterCubit.close();
    });

    test('initial state is 0', () {
      expect(counterCubit.state.count, 0);
    });

    blocTest<CounterCubit, CounterState>(
      'emits [1] when increment is called',
      build: () => counterCubit,
      act: () => counterCubit.increment(),
      expect: () => [CounterState(count: 1, status: CounterStateStatus.success)],
    );

    blocTest<CounterCubit, CounterState>(
      'emits [-1] when decrement is called',
      build: () => counterCubit,
      act: () => counterCubit.decrement(),
      expect: () => [CounterState(count: -1, status: CounterStateStatus.success)],
    );
  });
}

Explanation:

• We use blocTest from the bloc_test package to test our Cubit.
• build creates an instance of the CounterCubit.
• act calls the method we want to test (e.g., increment()).
• expect specifies the expected state that should be emitted after calling the method.

Run the tests:

Run flutter test in your terminal. You should see that all the tests pass.

8. Best Practices and Common Pitfalls (Avoid the Potholes!) 🚧

Here are some best practices to keep in mind when working with Cubit:

• Keep your Cubits small and focused: Each Cubit should be responsible for managing a specific part of your application’s state. Avoid creating monolithic Cubits that try to do everything.
• Use immutable state: Always create new state objects instead of modifying existing ones. This makes your state more predictable and easier to debug.
• Handle errors gracefully: Always wrap asynchronous operations in try...catch blocks and emit appropriate error states to the UI.
• Write tests: Thoroughly test your Cubits to ensure they behave as expected.
• Don’t over-engineer: Cubit is designed to be simple. Don’t try to add unnecessary complexity.

Common Pitfalls:

• Forgetting to close your Cubits: When a Cubit is no longer needed, you should call close() to release its resources. Failing to do so can lead to memory leaks. Wrap BlocProvider with dispose: (context, cubit) => cubit.close()
• Modifying state directly: Avoid modifying the state object directly. Always create a new state object based on the previous one.
• Tight coupling between Cubit and UI: Avoid directly accessing UI elements from your Cubit. Your Cubit should only be concerned with managing state.
• Ignoring error states: Always handle potential errors and update the UI accordingly. Don’t just let your app crash silently.

9. Conclusion: Farewell, and May Your States Be Manageable! 👋

Congratulations, class! You’ve successfully navigated the world of Cubit and learned how to use it to manage your Flutter application’s state.

Remember, Cubit is a powerful tool that can help you build cleaner, more maintainable, and more testable applications. Embrace its simplicity, follow the best practices, and avoid the common pitfalls.

Now go forth and conquer the world of state management! And if you get lost along the way, remember Professor Armchair is always here (probably) to help.

(Class dismissed! Go forth and code! 💻)