O gerenciamento de estado representa um desafio central no desenvolvimento Flutter. Riverpod e BLoC dominam o ecossistema, cada um oferecendo uma filosofia distinta. Este guia compara as duas soluções por meio de implementações concretas para orientar a escolha conforme as necessidades do projeto.

Pré-requisitos

Este guia pressupõe familiaridade com Flutter e os fundamentos de gerenciamento de estado. Os exemplos utilizam Riverpod 3.x e flutter_bloc 9.x, as versões estáveis atuais em 2026.

Filosofias Centrais das Duas Abordagens

Riverpod e BLoC resolvem o mesmo problema com paradigmas opostos. Compreender essas diferenças conceituais permite escolher a ferramenta certa para cada contexto.

Riverpod adota uma abordagem declarativa e reativa. Os providers definem fontes de dados que os widgets observam. O framework gerencia automaticamente o ciclo de vida, o cache e as dependências entre providers. A versão 3.0 traz melhorias significativas: retry automático para providers com falha, pausa/retomada de listeners conforme a visibilidade do widget, e persistência offline experimental.

BLoC (Business Logic Component) impõe uma arquitetura estrita orientada a eventos. Os componentes emitem eventos, o Bloc os processa e produz novos estados. Essa separação explícita facilita o rastreamento do fluxo de dados. A versão 9.x introduz EmittableStateStreamableSource para maior flexibilidade em testes.

riverpod_philosophy.dartdart

// Riverpod 3.x: Notifier replaces StateNotifier as the standard pattern
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;
  
  void increment() => state++;
}

// Usage in a widget
class CounterWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Reactive read: automatic rebuild if value changes
    final count = ref.watch(counterProvider);
    return Text('$count');
  }
}

bloc_philosophy.dartdart

// BLoC 9.x: explicit events/states separation
sealed class CounterEvent {}
final class IncrementPressed extends CounterEvent {}

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    // Each event has its dedicated handler
    on<IncrementPressed>((event, emit) => emit(state + 1));
  }
}

// Usage in a widget
class CounterWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocBuilder<CounterBloc, int>(
      builder: (context, count) => Text('$count'),
    );
  }
}

A escolha entre essas abordagens depende das preferências da equipe e das restrições do projeto. Para uma visão geral das opções de gerenciamento de estado incluindo GetX, consulte a comparação completa de state management Flutter para 2026.

Configuração Inicial

A configuração inicial revela diferenças ergonômicas entre as duas soluções. O Riverpod prioriza a simplicidade, o BLoC oferece mais estrutura.

Instalação do Riverpod

O Riverpod requer um único pacote e um wrapper na raiz da aplicação. A geração de código com riverpod_generator é a abordagem recomendada na versão 3.x.

main.dartdart

// Riverpod configuration: single wrapper at root
import 'package:flutter_riverpod/flutter_riverpod.dart';

void main() {
  runApp(
    // ProviderScope wraps the entire application
    const ProviderScope(
      child: MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: HomeScreen(),
    );
  }
}

Instalação do BLoC

O BLoC requer vários pacotes e uma configuração mais elaborada com BlocProviders para cada Bloc utilizado.

main.dartdart

// BLoC configuration: explicit providers for each Bloc
import 'package:flutter_bloc/flutter_bloc.dart';

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

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    // MultiBlocProvider for multiple Blocs
    return MultiBlocProvider(
      providers: [
        BlocProvider(create: (_) => AuthBloc()),
        BlocProvider(create: (_) => ThemeBloc()),
      ],
      child: MaterialApp(
        home: HomeScreen(),
      ),
    );
  }
}

A configuração do BLoC requer mais código inicial, mas torna as dependências explícitas desde o início.

Gerenciamento de Estado Simples: Contadores e Toggles

Casos simples ilustram a ergonomia diária de cada solução. O Riverpod se destaca pela concisão, o BLoC mantém sua estrutura orientada a eventos.

Contador com Riverpod (Padrão Notifier)

O Riverpod 3.x deprecia StateProvider e StateNotifierProvider em favor da API unificada Notifier. O novo padrão é mais limpo e funciona perfeitamente com a geração de código.

counter_riverpod.dartdart

// Notifier pattern: the standard in Riverpod 3.x
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

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

class CounterScreen extends ConsumerWidget {
  const CounterScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // watch for reactive value
    final count = ref.watch(counterProvider);

    return Scaffold(
      body: Center(child: Text('Count: $count')),
      floatingActionButton: FloatingActionButton(
        // read for actions (no rebuild)
        onPressed: () => ref.read(counterProvider.notifier).increment(),
        child: const Icon(Icons.add),
      ),
    );
  }
}

Contador com BLoC

counter_bloc.dartdart

// Typed events for each possible action
sealed class CounterEvent {}
final class CounterIncremented extends CounterEvent {}
final class CounterDecremented extends CounterEvent {}
final class CounterReset extends CounterEvent {}

// Bloc with handlers for each event
class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<CounterIncremented>((event, emit) => emit(state + 1));
    on<CounterDecremented>((event, emit) => emit(state - 1));
    on<CounterReset>((event, emit) => emit(0));
  }
}

class CounterScreen extends StatelessWidget {
  const CounterScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: BlocBuilder<CounterBloc, int>(
          builder: (context, count) => Text('Count: $count'),
        ),
      ),
      floatingActionButton: FloatingActionButton(
        // Event dispatch to modify state
        onPressed: () => context.read<CounterBloc>().add(CounterIncremented()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

Para casos simples, o Riverpod reduz significativamente o boilerplate. O BLoC se torna relevante quando a lógica ganha complexidade ou quando a rastreabilidade de eventos importa.

Providers legacy no Riverpod 3.x

StateProvider e StateNotifierProvider ainda funcionam, mas requerem importação de flutter_riverpod/legacy.dart. Para código novo, use Notifier ou AsyncNotifier.

Gerenciamento de Estado Assíncrono: Chamadas de API

Operações assíncronas revelam o poder de cada solução. Gerenciar os estados de carregamento, erro e dados constitui um desafio importante. O Riverpod 3.x introduz retry automático com backoff exponencial para providers com falha.

Dados Assíncronos com Riverpod

async_riverpod.dartdart

// AsyncNotifier: automatic loading/error/data management with retry
@riverpod
class Users extends _$Users {
  @override
  Future<List<User>> build() async {
    // autoDispose releases resources when provider is no longer used
    // Automatic retry on failure (exponential backoff: 200ms to 6.4s)
    final repository = ref.watch(userRepositoryProvider);
    return repository.fetchUsers();
  }

  Future<void> refresh() async {
    state = const AsyncLoading();
    state = await AsyncValue.guard(() => build());
  }
}

class UsersScreen extends ConsumerWidget {
  const UsersScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final usersAsync = ref.watch(usersProvider);

    // when handles all 3 possible states
    return usersAsync.when(
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (error, stack) => Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('Erro: $error'),
            ElevatedButton(
              // invalidate forces reload
              onPressed: () => ref.invalidate(usersProvider),
              child: const Text('Tentar novamente'),
            ),
          ],
        ),
      ),
      data: (users) => ListView.builder(
        itemCount: users.length,
        itemBuilder: (context, index) => UserTile(user: users[index]),
      ),
    );
  }
}

Dados Assíncronos com BLoC

async_bloc.dartdart

// Explicit states for each loading phase
sealed class UsersState {}
final class UsersInitial extends UsersState {}
final class UsersLoading extends UsersState {}
final class UsersLoaded extends UsersState {
  final List<User> users;
  UsersLoaded(this.users);
}
final class UsersError extends UsersState {
  final String message;
  UsersError(this.message);
}

// Events to trigger actions
sealed class UsersEvent {}
final class UsersFetchRequested extends UsersEvent {}
final class UsersRefreshRequested extends UsersEvent {}

class UsersBloc extends Bloc<UsersEvent, UsersState> {
  final UserRepository _repository;

  UsersBloc(this._repository) : super(UsersInitial()) {
    on<UsersFetchRequested>(_onFetchRequested);
    on<UsersRefreshRequested>(_onRefreshRequested);
  }

  Future<void> _onFetchRequested(
    UsersFetchRequested event,
    Emitter<UsersState> emit,
  ) async {
    emit(UsersLoading());
    try {
      final users = await _repository.fetchUsers();
      emit(UsersLoaded(users));
    } catch (e) {
      emit(UsersError(e.toString()));
    }
  }

  Future<void> _onRefreshRequested(
    UsersRefreshRequested event,
    Emitter<UsersState> emit,
  ) async {
    // Keep current state during refresh
    final currentState = state;
    try {
      final users = await _repository.fetchUsers();
      emit(UsersLoaded(users));
    } catch (e) {
      // Restore previous state on error
      if (currentState is UsersLoaded) {
        emit(currentState);
      } else {
        emit(UsersError(e.toString()));
      }
    }
  }
}

users_screen_bloc.dartdart

// Widget with pattern matching on states
class UsersScreen extends StatelessWidget {
  const UsersScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UsersBloc, UsersState>(
      builder: (context, state) {
        return switch (state) {
          UsersInitial() => Center(
              child: ElevatedButton(
                onPressed: () => context.read<UsersBloc>().add(UsersFetchRequested()),
                child: const Text('Carregar'),
              ),
            ),
          UsersLoading() => const Center(child: CircularProgressIndicator()),
          UsersError(:final message) => Center(
              child: Column(
                mainAxisAlignment: MainAxisAlignment.center,
                children: [
                  Text('Erro: $message'),
                  ElevatedButton(
                    onPressed: () => context
                        .read<UsersBloc>()
                        .add(UsersFetchRequested()),
                    child: const Text('Tentar novamente'),
                  ),
                ],
              ),
            ),
          UsersLoaded(:final users) => ListView.builder(
              itemCount: users.length,
              itemBuilder: (context, index) => UserTile(user: users[index]),
            ),
        };
      },
    );
  }
}

O BLoC oferece controle granular sobre cada transição de estado. O Riverpod automatiza mais via AsyncValue e a lógica de retry integrada.

Pronto para mandar bem nas entrevistas de Flutter?

Pratique com nossos simuladores interativos, flashcards e testes tecnicos.

Explorar Flutter

Dependências entre Estados: Composição e Injeção

Aplicações reais envolvem estados interdependentes. O gerenciamento dessas dependências diferencia significativamente as duas abordagens.

Composição com Riverpod

composition_riverpod.dartdart

// Base provider: configuration
@riverpod
ApiClient apiClient(Ref ref) {
  final baseUrl = ref.watch(environmentProvider).apiUrl;
  return ApiClient(baseUrl: baseUrl);
}

// Dependent provider: repository
@riverpod
ProductRepository productRepository(Ref ref) {
  // Automatic client injection
  final client = ref.watch(apiClientProvider);
  return ProductRepository(client);
}

// Provider with parameter: product by ID
@riverpod
Future<Product> product(Ref ref, String productId) async {
  final repository = ref.watch(productRepositoryProvider);
  return repository.getProduct(productId);
}

// Derived provider: filtered products
@riverpod
List<Product> filteredProducts(Ref ref) {
  final products = ref.watch(productsProvider).valueOrNull ?? [];
  final filter = ref.watch(productFilterProvider);

  return products.where((p) => p.category == filter.category).toList();
}

// Usage with parameter
class ProductDetailScreen extends ConsumerWidget {
  final String productId;

  const ProductDetailScreen({super.key, required this.productId});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // family allows passing parameters
    final productAsync = ref.watch(productProvider(productId));

    return productAsync.when(
      loading: () => const ProductSkeleton(),
      error: (e, _) => ErrorWidget(error: e),
      data: (product) => ProductDetails(product: product),
    );
  }
}

Composição com BLoC

composition_bloc.dartdart

// Repository injected into the Bloc
class ProductBloc extends Bloc<ProductEvent, ProductState> {
  final ProductRepository _repository;
  final CartBloc _cartBloc;
  late final StreamSubscription _cartSubscription;

  ProductBloc({
    required ProductRepository repository,
    required CartBloc cartBloc,
  })  : _repository = repository,
        _cartBloc = cartBloc,
        super(ProductInitial()) {
    on<ProductFetchRequested>(_onFetchRequested);
    on<ProductAddedToCart>(_onAddedToCart);

    // Listen to cart changes
    _cartSubscription = _cartBloc.stream.listen((cartState) {
      // React to cart changes
      if (cartState is CartUpdated) {
        add(ProductCartSyncRequested(cartState.items));
      }
    });
  }

  Future<void> _onFetchRequested(
    ProductFetchRequested event,
    Emitter<ProductState> emit,
  ) async {
    emit(ProductLoading());
    try {
      final product = await _repository.getProduct(event.productId);
      // Check if product is in cart
      final isInCart = _cartBloc.state.contains(product.id);
      emit(ProductLoaded(product, isInCart: isInCart));
    } catch (e) {
      emit(ProductError(e.toString()));
    }
  }

  @override
  Future<void> close() {
    _cartSubscription.cancel();
    return super.close();
  }
}

// Configuration with dependency injection
class ProductsPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (context) => ProductBloc(
        repository: context.read<ProductRepository>(),
        cartBloc: context.read<CartBloc>(),
      )..add(ProductFetchRequested()),
      child: const ProductsView(),
    );
  }
}

O Riverpod gerencia dependências de forma declarativa. O BLoC requer gerenciamento manual das assinaturas entre Blocs.

Testabilidade e Mocking

Os testes constituem um critério decisivo para projetos profissionais. As duas soluções se destacam neste ponto com abordagens diferentes. Habilidades de testing são frequentemente avaliadas em entrevistas Flutter.

Testes com Riverpod

test_riverpod.dartdart

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';

class MockUserRepository extends Mock implements UserRepository {}

void main() {
  group('UserProvider Tests', () {
    late MockUserRepository mockRepository;

    setUp(() {
      mockRepository = MockUserRepository();
    });

    test('returns users from repository', () async {
      // Arrange
      final expectedUsers = [User(id: '1', name: 'Test')];
      when(() => mockRepository.fetchUsers())
          .thenAnswer((_) async => expectedUsers);

      // ProviderContainer.test auto-disposes after test
      final container = ProviderContainer.test(
        overrides: [
          userRepositoryProvider.overrideWithValue(mockRepository),
        ],
      );

      // Act
      final users = await container.read(usersProvider.future);

      // Assert
      expect(users, expectedUsers);
      verify(() => mockRepository.fetchUsers()).called(1);
    });

    test('handles repository errors', () async {
      when(() => mockRepository.fetchUsers())
          .thenThrow(Exception('Network error'));

      final container = ProviderContainer.test(
        overrides: [
          userRepositoryProvider.overrideWithValue(mockRepository),
        ],
      );

      expect(
        () => container.read(usersProvider.future),
        throwsException,
      );
    });
  });
}

Testes com BLoC

test_bloc.dartdart

import 'package:bloc_test/bloc_test.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';

class MockUserRepository extends Mock implements UserRepository {}

void main() {
  group('UsersBloc Tests', () {
    late MockUserRepository mockRepository;

    setUp(() {
      mockRepository = MockUserRepository();
    });

    // blocTest simplifies state sequence testing
    blocTest<UsersBloc, UsersState>(
      'emits [Loading, Loaded] when fetch succeeds',
      build: () {
        when(() => mockRepository.fetchUsers())
            .thenAnswer((_) async => [User(id: '1', name: 'Test')]);
        return UsersBloc(mockRepository);
      },
      act: (bloc) => bloc.add(UsersFetchRequested()),
      expect: () => [
        isA<UsersLoading>(),
        isA<UsersLoaded>().having(
          (s) => s.users.length,
          'users count',
          1,
        ),
      ],
    );

    blocTest<UsersBloc, UsersState>(
      'emits [Loading, Error] when fetch fails',
      build: () {
        when(() => mockRepository.fetchUsers())
            .thenThrow(Exception('Network error'));
        return UsersBloc(mockRepository);
      },
      act: (bloc) => bloc.add(UsersFetchRequested()),
      expect: () => [
        isA<UsersLoading>(),
        isA<UsersError>(),
      ],
    );
  });
}

O pacote bloc_test oferece sintaxe dedicada para testar sequências de estado. O Riverpod 3.x adiciona ProviderContainer.test() para dispose automático e NotifierProvider.overrideWithBuild() para mockar apenas o método build.

Cobertura de Testes

Testar apenas casos nominais é insuficiente. Os testes precisam cobrir erros de rede, timeouts, estados-limite e transições de estado inesperadas. Para práticas de testing completas, consulte o guia de testing Flutter.

Desempenho e Otimização de Rebuilds

O desempenho impacta diretamente a experiência do usuário. As duas soluções oferecem mecanismos distintos de otimização.

Otimização com Riverpod

perf_riverpod.dartdart

// select to rebuild only if targeted value changes
class UserNameWidget extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Rebuilds only if user.name changes
    final name = ref.watch(userProvider.select((user) => user.name));
    return Text(name);
  }
}

// Provider with automatic caching
@riverpod
ExpensiveResult expensiveComputation(Ref ref) {
  final input = ref.watch(inputProvider);
  // Computation automatically cached
  return performExpensiveComputation(input);
}

// keepAlive with timer for temporary caching
@riverpod
Future<List<Product>> searchResults(Ref ref, String query) async {
  // Temporary keepAlive during typing
  final link = ref.keepAlive();

  // Timer to release after inactivity
  final timer = Timer(const Duration(seconds: 30), link.close);
  ref.onDispose(timer.cancel);

  return searchProducts(query);
}

Otimização com BLoC

perf_bloc.dartdart

// buildWhen limits rebuilds conditionally
class UserNameWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UserBloc, UserState>(
      // Rebuilds only if name changes
      buildWhen: (previous, current) {
        if (previous is UserLoaded && current is UserLoaded) {
          return previous.user.name != current.user.name;
        }
        return true;
      },
      builder: (context, state) {
        if (state is UserLoaded) {
          return Text(state.user.name);
        }
        return const SizedBox.shrink();
      },
    );
  }
}

// BlocSelector to extract a specific value
class UserAvatarWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocSelector<UserBloc, UserState, String?>(
      // Select only the avatar URL
      selector: (state) => state is UserLoaded ? state.user.avatarUrl : null,
      builder: (context, avatarUrl) {
        if (avatarUrl == null) return const DefaultAvatar();
        return NetworkImage(avatarUrl);
      },
    );
  }
}

As duas soluções oferecem otimizações granulares. Riverpod com select, BLoC com buildWhen e BlocSelector. Para técnicas avançadas de performance, consulte o guia de otimização de performance Flutter.

Caso Prático: Autenticação Completa

Um sistema de autenticação ilustra os padrões reais de cada solução. Este caso combina estado persistente, chamadas de API e navegação.

Autenticação com Riverpod

auth_riverpod.dartdart

// Authentication state with sealed class
sealed class AuthState {
  const AuthState();
}
final class AuthInitial extends AuthState {
  const AuthInitial();
}
final class AuthLoading extends AuthState {
  const AuthLoading();
}
final class AuthAuthenticated extends AuthState {
  final User user;
  const AuthAuthenticated(this.user);
}
final class AuthUnauthenticated extends AuthState {
  final String? error;
  const AuthUnauthenticated([this.error]);
}

// Notifier to manage auth state
@riverpod
class Auth extends _$Auth {
  @override
  Future<AuthState> build() async {
    final storage = ref.watch(secureStorageProvider);
    final repository = ref.watch(authRepositoryProvider);
    
    final token = await storage.getToken();
    if (token != null) {
      try {
        final user = await repository.getCurrentUser(token);
        return AuthAuthenticated(user);
      } catch (_) {
        await storage.deleteToken();
        return const AuthUnauthenticated();
      }
    }
    return const AuthUnauthenticated();
  }

  Future<void> login(String email, String password) async {
    state = const AsyncLoading();
    final repository = ref.read(authRepositoryProvider);
    final storage = ref.read(secureStorageProvider);
    
    try {
      final result = await repository.login(email, password);
      await storage.saveToken(result.token);
      state = AsyncData(AuthAuthenticated(result.user));
    } catch (e) {
      state = AsyncData(AuthUnauthenticated(e.toString()));
    }
  }

  Future<void> logout() async {
    final storage = ref.read(secureStorageProvider);
    await storage.deleteToken();
    state = const AsyncData(AuthUnauthenticated());
  }
}

// Redirect based on auth state
@riverpod
GoRouter router(Ref ref) {
  final authState = ref.watch(authProvider);

  return GoRouter(
    redirect: (context, state) {
      final isAuth = authState.valueOrNull is AuthAuthenticated;
      final isAuthRoute = state.matchedLocation.startsWith('/auth');

      if (!isAuth && !isAuthRoute) return '/auth/login';
      if (isAuth && isAuthRoute) return '/home';
      return null;
    },
    routes: [...],
  );
}

Autenticação com BLoC

auth_bloc.dartdart

// Exhaustive states for authentication
sealed class AuthState {
  const AuthState();
}
final class AuthInitial extends AuthState {
  const AuthInitial();
}
final class AuthCheckInProgress extends AuthState {
  const AuthCheckInProgress();
}
final class AuthLoginInProgress extends AuthState {
  const AuthLoginInProgress();
}
final class AuthSuccess extends AuthState {
  final User user;
  const AuthSuccess(this.user);
}
final class AuthFailure extends AuthState {
  final String error;
  const AuthFailure(this.error);
}
final class AuthLoggedOut extends AuthState {
  const AuthLoggedOut();
}

// Authentication events
sealed class AuthEvent {
  const AuthEvent();
}
final class AuthCheckRequested extends AuthEvent {
  const AuthCheckRequested();
}
final class AuthLoginSubmitted extends AuthEvent {
  final String email;
  final String password;
  const AuthLoginSubmitted(this.email, this.password);
}
final class AuthLogoutRequested extends AuthEvent {
  const AuthLogoutRequested();
}

class AuthBloc extends Bloc<AuthEvent, AuthState> {
  final AuthRepository _repository;
  final SecureStorage _storage;

  AuthBloc({
    required AuthRepository repository,
    required SecureStorage storage,
  })  : _repository = repository,
        _storage = storage,
        super(const AuthInitial()) {
    on<AuthCheckRequested>(_onCheckRequested);
    on<AuthLoginSubmitted>(_onLoginSubmitted);
    on<AuthLogoutRequested>(_onLogoutRequested);
  }

  Future<void> _onCheckRequested(
    AuthCheckRequested event,
    Emitter<AuthState> emit,
  ) async {
    emit(const AuthCheckInProgress());
    final token = await _storage.getToken();

    if (token == null) {
      emit(const AuthLoggedOut());
      return;
    }

    try {
      final user = await _repository.getCurrentUser(token);
      emit(AuthSuccess(user));
    } catch (_) {
      await _storage.deleteToken();
      emit(const AuthLoggedOut());
    }
  }

  Future<void> _onLoginSubmitted(
    AuthLoginSubmitted event,
    Emitter<AuthState> emit,
  ) async {
    emit(const AuthLoginInProgress());
    try {
      final result = await _repository.login(event.email, event.password);
      await _storage.saveToken(result.token);
      emit(AuthSuccess(result.user));
    } catch (e) {
      emit(AuthFailure(e.toString()));
    }
  }

  Future<void> _onLogoutRequested(
    AuthLogoutRequested event,
    Emitter<AuthState> emit,
  ) async {
    await _storage.deleteToken();
    emit(const AuthLoggedOut());
  }
}

As duas implementações cobrem a mesma funcionalidade com estilos diferentes. O BLoC explicita cada transição, o Riverpod simplifica a sintaxe.

Tabela Comparativa Resumo

Critério	Riverpod 3.x	BLoC 9.x
Curva de aprendizado	Moderada	Mais íngreme
Boilerplate	Mínimo (com codegen)	Significativo
Type Safety	Excelente	Excelente
Testabilidade	Excelente	Excelente
Retry automático	Integrado	Implementação manual
Persistência offline	Suporte experimental	Pacotes externos
Rastreabilidade	Via DevTools	Eventos/Estados explícitos
Composição	Automática	Manual
Geração de código	Recomendada	Não necessária
Tamanho da equipe	Flexível	Equipes grandes

Recomendações por Contexto

A escolha entre Riverpod e BLoC depende de vários fatores contextuais.

Escolher Riverpod quando:

A equipe prioriza concisão e produtividade
O projeto requer composição flexível de estado
Os desenvolvedores vêm do React ou de outros frameworks reativos
O retry automático e a recuperação de erros importam
A persistência offline é um requisito

Escolher BLoC quando:

A equipe valoriza padrões estritos e previsíveis
O projeto exige rastreabilidade completa de eventos para auditoria
Os juniores se beneficiam de uma arquitetura imposta
A depuração requer histórico de transições detalhado
A indústria exige trilhas de auditoria (fintech, saúde)

Fontes

Riverpod 3.0 What's New: retry automático, pausa/retomada, persistência offline
Riverpod 3.0 Migration Guide: Notifier substitui StateNotifier
flutter_bloc 9.0.0 Changelog: EmittableStateStreamableSource, melhorias de testing
BLoC Documentation: padrões oficiais e boas práticas

Pontos-chave de Riverpod vs BLoC em 2026

Riverpod e BLoC atendem com eficácia às necessidades de gerenciamento de estado no Flutter. O Riverpod 3.x se destaca em ergonomia, tratamento automático de erros e composição flexível. O BLoC 9.x lidera em estrutura, previsibilidade e rastreabilidade de nível empresarial. As duas soluções oferecem excelente testabilidade e desempenho otimizado.

Checklist de Decisão

Avaliar o tamanho e a experiência da equipe
Considerar a complexidade do fluxo de dados
Analisar as necessidades de rastreabilidade e depuração
Testar as duas soluções em um protótipo
Verificar a coerência com a arquitetura existente

Comece a praticar!

Teste seus conhecimentos com nossos simuladores de entrevista e testes tecnicos.

Criar minha conta gratis

A melhor escolha continua sendo aquela que a equipe domina e mantém de forma eficaz. A consistência na aplicação tem prioridade sobre a escolha da solução em si. Para padrões específicos de Dart como isolates e concorrência, consulte o guia de isolates e concorrência Dart.

Gerenciamento de Estado no Flutter: Riverpod vs BLoC - Guia Comparativo Completo