Compare Provider, Riverpod and Bloc.

All three solve access and rebuilds, but they optimize for different things. Provider depends on BuildContext and is easy to learn. Riverpod removes the context dependency for reads, supports auto-disposal and provider composition, and makes overrides straightforward in tests. Bloc exposes a unidirectional event-to-state flow that is easy to log and reason about in large features.

• Provider: small surface area, context-based lookup, good for simple apps
• Riverpod: providers are declared globally, testable with overrides, strong async support
• Bloc: explicit events and states, strong traceability, more ceremony per feature
• Bloc often pairs with repository and use-case layers; Riverpod can replace that wiring

final userProvider = FutureProvider.autoDispose<User>((ref) async {
  final repository = ref.watch(userRepositoryProvider);
  return repository.fetchCurrentUser();
});

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final user = ref.watch(userProvider);
    return user.when(
      data: (value) => Text(value.name),
      loading: () => const CircularProgressIndicator(),
      error: (error, stack) => const Text('Failed to load profile'),
    );
  }
}

Trade-offs in practice

Provider can become hard to trace when many widgets read many models and lifecycle is implicit. Riverpod's global providers are not global mutable state, but the team still needs conventions for provider ownership. Bloc's ceremony pays off when state transitions must be auditable, but it can be heavy for a small settings screen.