Why we decided to switch from Bloc to Riverpod

Where did the idea come from?

It's no secret that choosing the right state manager, architecture, and structure plays a significant role in the development of a project. In this article, we'll focus on the first point — the state manager.

We used Bloc for a long time on all our projects. It's a great solution for state management, but it has a number of drawbacks that we regularly encountered during work. Now, let's talk about each of these in more detail.

• Variability of approaches to logic implementation. Bloc includes several components that lean towards different architectural approaches — the lightweight Cubit and the full-fledged Bloc. This variability can be both a plus and a minus, as it can lead to developer disunity and mix approaches during development.

• Boilerplate. When using a full-fledged Bloc, you have to write a lot of repetitive boilerplate — describing events for a page and registering the necessary handlers in the Bloc itself. While this feature may not be as noticeable in small applications, it becomes a real torture in large projects.

• Imposing libraries for use. This point is directly related to the Bloc developer. To test the logic, bloc_test, which includes mocktail, is used. Bloc_test itself is a great tool that allows you to thoroughly test behavior, but by adding this dependency to pubspec, we automatically pull in mocktail. Thus, the library developer does not provide alternatives and imposes their libraries, which we would prefer not to use.

• Mocktail. It forces us to manually create mocks, while our team is used to automating such processes. Therefore, here we prefer Mockito.

These combined factors led us to consider alternative options for state management. We needed a state manager that would solve all these problems but still preserve ease of use and sufficient code readability. Currently, there are a lot of solutions with their own pros and cons. We researched the most popular ones and decided to settle on one — Riverpod.
 

State Manager Options

When exploring the existing libraries, we evaluated them based on important criteria for us:

• Documentation

• Amount of boilerplate

• Testability

• Community size and possible risks

We considered: Bloc, Riverpod, Triple, GetX, Provider, Redux, and several of its wrappers — Fish Redux and Async Redux. We assessed the pros and cons of each option, and some libraries were immediately ruled out due to significant drawbacks and not meeting our requirements. As a result of the comparative analysis, only two new libraries remained for us — Riverpod and Triple.

We wanted to get to know these libraries better, so we implemented a small test project with each of the managers, which helped us choose a favorite. Riverpod turned out to be more convenient than Triple, more documented, and had greater community support. Thus, we decided to use the more popular solution to minimize risks.
If choosing a specific technology is relevant for you, we recommend applying each of the considered libraries to a small test project to get an idea of their use and decide what suits you best.

We also compared code in Riverpod against code in Bloc. And this comparison exceeded all expectations. It turned out that everything with Riverpod looks, writes, and reads much simpler than the same thing implemented in Bloc. This assured us that we could achieve the desired result by applying the new manager. Now we propose to focus on the main differences between these two libraries. 

Key Differences Between Riverpod and Bloc

Let's take a look at the code for working with a todo-list using Riverpod. 

class TodoProvider extends StateNotifier<TodoState> {
  TodoProvider(
    this._todoRepository, {
    @visibleForTesting TodoState? initialState,
  }) : super(initialState ?? const TodoState());

  final TodoRepository _todoRepository;

  Future<void> initializeTodos() async {
    final savedTodos = await _todoRepository.fetchAll();
    
    // To-do list fetches from Hive, so it doesn't take much time.
    // In this case we use one second delay to avoid blink of progress bar
    await Future.delayed(const Duration(seconds: 1), () {
      state = state.copyWith(
        isLoading: false,
        todos: savedTodos.entries.map(TodoUi.fromMapEntry).toList(),
      );
    });
  }

Future<void> createTodo(String todo) async {
    await _todoRepository.save(TodoHive(todo));
    final savedTodos = await _todoRepository.fetchAll();
    state = state.copyWith(
      todos: savedTodos.entries.map(TodoUi.fromMapEntry).toList(),
    );
  }

  Future<void> removeTodo(int key) async {
    await _todoRepository.removeByKey(key);
    state = state.copyWith(
      todos: List.of(state.todos)..removeWhere((element) => element.key == key),
    );
  }
}

abstract class TodoEvent extends Equatable {
  const TodoEvent();

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

class TodoInitialed extends TodoEvent {
  const TodoInitialed();
}

class TodoCreated extends TodoEvent {
  const TodoCreated(this.todo);

  final String todo;

  @override
  List<Object?> get props => [todo];
}

class TodoRemoved extends TodoEvent {
  const TodoRemoved(this.key);

  final int key;

  @override
  List<Object?> get props => [key];
}

class TodoBloc extends Bloc<TodoEvent, TodoState> {
  TodoBloc(TodoRepository todoRepository)
      : _todoRepository = todoRepository,
        super(const TodoState.initial()) {
    on<TodoInitialed>(_onTodoInitialed);
    on<TodoCreated>(_onTodoCreated);
    on<TodoRemoved>(_onTodoRemoved);
  }

final TodoRepository _todoRepository;

  Future<void> _onTodoInitialed(TodoInitialed event, Emitter emit) async {
    final savedTodos = await _todoRepository.fetchAll();
    await Future.delayed(const Duration(seconds: 1), () {
      emit(TodoState.update(
        savedTodos.entries
            .map<TodoUi>((e) => TodoUi.fromHiveModel(e.key as int, e.value))
            .toList(),
      ));
    });
  }

  Future<void> _onTodoCreated(TodoCreated event, Emitter emit) async {
    await _todoRepository.save(TodoHive(event.todo));
    final savedTodos = await _todoRepository.fetchAll();
    emit(TodoState.update(
      savedTodos.entries
          .map<TodoUi>((e) => TodoUi.fromHiveModel(e.key as int, e.value))
          .toList(),
    ));
  }

  Future<void> _onTodoRemoved(TodoRemoved event, Emitter emit) async {
    await _todoRepository.removeByKey(event.key);
    emit(TodoState.update(List.of(state.todos)
      ..removeWhere((element) => element.key == event.key)));
  }
}

In-depth Analysis

It’s one thing to apply a library, and another to look at its internal structure to understand the code quality and internal principles.

The most frequently used object in a project is StateNotifier, which allows you to operate with more complex entities consisting of the required set of primitives—classes. Essentially, it works just like Bloc, but the handler is called directly.

In the case of Bloc, when an event comes in, it is matched with a registered handler for that event type. After executing the necessary actions, the handler places a new state in the StreamController. This is the state we listen to in the UI. Using Stream guarantees regular state updates when new events arrive.

Finding differences in the logic of Riverpod’s operation, in this sense, is not particularly appropriate because the principle of operation is almost the same. However, there is a difference in another aspect, which we will discuss now.

Bloc uses its own Provider extension, which allows screen rebuilding when the state changes. It is based on working with the application context, so we need to wrap the necessary widgets in BlocProvider to give access to the Bloc to the underlying subtree. To work with the state itself, a BlocBuilder or its advanced analog, BlocConsumer, is required.

Riverpod differs in that it does not rely on context. It creates its own container for providers, eliminating the need for additional wrappers to get our state. This reduces unnecessary nesting in the tree. Moreover, Riverpod can be adapted as a Dependency Injection to use objects in any layer of the application. Just have a ref-reference to get the necessary infrastructure object, data, or state. This adds more flexibility to usage, though it places more responsibility on the developer.

Both libraries provide identical tools for working in the UI layer. There is the ability to subscribe to multiple providers, rebuild the screen depending on specific parameters, use convenient extensions, etc.

The difference lies only in the syntax, which in any case is an individual point in any applicable solution.

First Experience Using Riverpod

In new projects, we decided to use the chosen technology, but before that, it would be good to test it out. Management came up with the idea to ease internal company management processes by implementing our own application. We decided to get better acquainted with the new technology on it.

Riverpod suited our project structure quite well, so the transition to it was easy. We got a better understanding of state management methods and registering the dependencies we needed, and the development went much faster and became more interesting. The boilerplate code significantly reduced, which was literally a breath of fresh air for us.

Soon, a new commercial project aimed at the agricultural sector of some African countries began. The project is quite large, involving several user roles, and describing all the events for each screen with Bloc would have been torturous. Development with Riverpod went quite smoothly. Overall, the code turned out to be quite beautiful and concise. The project is already fully implemented and launched into production. Therefore, based on this practical experience, we can highlight both positive and negative aspects.

blocTest<TodoBloc, TodoState>(
  'Check getting initial todos',
  build: () {
    when(todoRepository.fetchAll()).thenAnswer((_) async => savedTodos);
    return bloc;
  },
  act: (bloc) => bloc.add(const TodoInitialed()),
  wait: const Duration(seconds: 1),
  expect: () => [
    const TodoState.update(savedTodosUi),
  ],
);

test('Check get all todos', () async {
  when(todoRepository.fetchAll()).thenAnswer((_) async => savedTodos);
  
  await container.read(provider.notifier).initializeTodos();
  await Future<void>.delayed(const Duration(seconds: 1));
  expect(container.read(provider).todos, savedTodosUi);
});

TodoProvider(
  this._todoRepository, {
  @visibleForTesting TodoState? initialState,
}) : super(initialState ?? const TodoState());

Conclusion

At the moment, we are completely satisfied with using Riverpod. It is convenient and provides us, as developers, with everything necessary for the quick and comfortable development of applications. It fully meets all our requirements for a state manager.

Thanks to this change, we were able to shift our focus to other aspects of our code. We redesigned the error-handling system, paid more attention to Dependency Injection, set new goals in testing, and revised some architectural approaches. Thus, the change of state manager became not just a pleasant improvement but a new driving force in the development of our codebase, which also reflects in the overall development of our team.

Let's summarize the points we managed to address by applying the new state manager:

• Unlike Bloc, Riverpod does not contain additional tools for implementing logic, such as Cubit. We only have a set of providers that work with states or needed objects. In other words, we eliminated unnecessary variability and can be sure that all code will be written in the same architectural approach.

• Minimized boilerplate. We no longer need to generate essentially identical code describing all methods of user interaction with the screen. We no longer need event classes and all additional wrappers like BlocProvider and BlocConsumer.

• Tests have become simpler. Previously, Bloc was used with bloc_test, which were quite cumbersome. Now, within simple tests, providers can be tested for all necessary cases.

• We are no longer under the influence of the Bloc developer and can independently choose the technology stack that suits us best.

• Working with state in the UI has become more convenient. A specific widget can be easily subscribed to updates through ref.watch.

• We also gained new experiences and insights from working with Riverpod, further broadening our expertise and perspective.