Houssam Eddine | Portfolio

Why This Tutorial Exists

This tutorial aims to share some insights about BlocProvider implementation patterns in Flutter. Through community discussions and shared experiences on platforms like Stack Overflow, I noticed some common challenges developers face when implementing state management with BLoC. Let's explore together some effective approaches and best practices that can help create more maintainable Flutter applications.

Key Motivations:

The Problem

A Stack Overflow answer with 36 upvotes was promoting a global BlocProvider pattern that could lead to serious performance issues and memory leaks.

The Goal

To provide clear, practical guidance on proper bloc implementation, backed by insights from the bloc library creator himself.

The Impact

Help developers avoid common pitfalls and build more maintainable, performant Flutter applications.

What You'll Learn:

Proper BlocProvider implementation patterns
Common pitfalls and how to avoid them
Performance implications of different approaches

Best practices for state management
Real-world examples and solutions
Insights from the bloc library creator

Prerequisites

Basic understanding of Flutter development
Familiarity with the BLoC pattern concept
Flutter development environment set up

Common BlocProvider Issues

View Original Discussion

Stack Overflow Question

Understanding Context Issues with BlocProvider

Common Error: "BlocProvider.of() called with a context that does not contain a Bloc"

Typical Scenario

Consider a common Flutter application structure with authentication flow:

plaintext

App() => LoginPage() => HomePage() => UserTokensPage()

Many developers start with this seemingly correct implementation:

Initial Implementation

dart

void main() => runApp(App());

class App extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'My App',
      home: BlocProvider<UserBloc>(
        create: (context) => UserBloc(UserRepository()),
        child: LoginPage(),
      ),
    );
  }
}

This implementation can lead to context-related issues when navigating between pages

Why This Can Be Problematic:

Bloc access lost during navigation
Context scope limited to LoginPage
State management becomes inconsistent

The Misleading Solution

View Original Discussion

Warning: This approach can lead to performance issues

A highly upvoted answer suggested wrapping the entire app with MultiBlocProvider:

dart

void main() {
  runApp(
    MultiBlocProvider(
      providers: [
        BlocProvider<UserBloc>(
          create: (context) => UserBloc(UserRepository()),
        ),
        // More global providers...
      ],
      child: App()
    )
  );
}

Why This Solution Is Problematic:

Memory Issues

Blocs are never disposed
Resources are consumed unnecessarily
Memory leaks can occur

State Management Issues

Global state becomes complex
Requires manual state resets
Poor feature isolation

The Verified Solution

View Original Discussion

While a correct solution was provided and verified with a checkmark, it didn't address or correct the misleading approach suggested in the other answer. This missed opportunity to warn developers about the potential issues with the global BlocProvider implementation.

Insights from the Creator

View GitHub Issue

Felix Angelov (bloc library creator)March 10, 2022

The main disadvantages of providing all blocs globally are:
Blocs are never closed so they are consuming resources even if they aren't being used by the current widget tree
Blocs can be accessed from anywhere even if the state of the bloc is scoped to just a particular feature
Blocs typically end up needing some sort of "reset" event to revert back to the initial state
Recommendation: Create a bloc per feature and provide that bloc only to the specific subtree that needs it.

Key Takeaways:

Scoped Access

Limit bloc access to only the widgets that need it

Resource Management

Ensure proper disposal of blocs when not needed

Feature Isolation

Maintain clear boundaries between features

Proper BlocProvider Disposal

Best Practice

Login Flow Example

Common Mistake: Keeping login-related blocs active after successful authentication

Proper Implementation:

dart

class LoginPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (context) => LoginBloc(
        authRepository: context.read<AuthRepository>(),
      ),
      child: LoginView(),
    );
  }
}

class LoginView extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return BlocListener<LoginBloc, LoginState>(
      listener: (context, state) {
        if (state.status == LoginStatus.success) {
          // Navigate and remove login route from stack
          Navigator.of(context).pushReplacement(
            MaterialPageRoute(builder: (_) => HomePage()),
          );
          // LoginBloc will be automatically disposed
        }
      },
      child: // Your login form widgets
    );
  }
}

Benefits of Proper Disposal:

Memory Efficiency

Resources freed after use
No memory leaks
Better app performance

State Management

Clean state transitions
No state conflicts
Predictable behavior

Code Organization

Better feature isolation
Clearer dependencies
Easier maintenance

Pro Tips:

• Use pushReplacement instead of push to remove the login page from navigation stack
• Scope blocs to specific features rather than making them global
• Let the widget tree handle bloc lifecycle through proper widget disposal
• Consider using BlocProvider.value only when passing existing bloc instances

Understanding MultiBlocProvider Usage

Best Practice

When and How to Use MultiBlocProvider

MultiBlocProvider isn't inherently bad — it's about using it correctly and when necessary.

Good Use Cases for MultiBlocProvider:

dart

// Example: Dashboard page requiring multiple related features
class DashboardPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiBlocProvider(
      providers: [
        BlocProvider<UserStatsBloc>(
          create: (context) => UserStatsBloc()..add(LoadUserStats()),
        ),
        BlocProvider<NotificationsBloc>(
          create: (context) => NotificationsBloc()..add(LoadNotifications()),
        ),
        BlocProvider<ActivityBloc>(
          create: (context) => ActivityBloc()..add(LoadRecentActivity()),
        ),
      ],
      child: DashboardView(),
    );
  }
}

Appropriate vs Inappropriate Usage:

Good Usage

Feature-Specific Pages:

When multiple blocs are needed for a specific feature's functionality

DashboardPage with related stats, notifications, and activity blocs

Related Data Management:

When blocs have interdependent functionality

Shopping cart with inventory and payment blocs

Scoped Feature Sets:

When multiple blocs share the same lifecycle

User profile with settings and preferences blocs

Bad Usage

Global App State:

Don't wrap MaterialApp with unrelated blocs

Wrapping entire app with authentication, settings, and cart blocs

Unrelated Features:

Don't combine blocs that serve different purposes

Mixing login bloc with product catalog bloc

Different Lifecycles:

Don't combine blocs with different disposal needs

Combining temporary chat bloc with persistent theme bloc

Practical Implementation Example:

dart

// E-commerce product detail page example
class ProductDetailPage extends StatelessWidget {
  final String productId;

  ProductDetailPage({required this.productId});

  @override
  Widget build(BuildContext context) {
    return MultiBlocProvider(
      providers: [
        BlocProvider<ProductDetailBloc>(
          create: (context) => ProductDetailBloc()
            ..add(LoadProductDetails(productId)),
        ),
        BlocProvider<ProductReviewsBloc>(
          create: (context) => ProductReviewsBloc()
            ..add(LoadProductReviews(productId)),
        ),
        BlocProvider<RelatedProductsBloc>(
          create: (context) => RelatedProductsBloc()
            ..add(LoadRelatedProducts(productId)),
        ),
      ],
      child: ProductDetailView(),
    );
  }
}

// These blocs will be disposed when leaving ProductDetailPage

Best Practices:

• Group blocs that are logically related and share the same lifecycle
• Dispose of blocs when their feature/page is no longer needed
• Consider performance implications of initializing multiple blocs
• Use lazy loading when possible to defer bloc creation
• Keep bloc providers as close as possible to where they're needed

Common Pitfalls to Avoid:

• Don't use MultiBlocProvider at app root unless absolutely necessary
• Avoid mixing blocs with different scopes or lifecycles
• Don't initialize blocs that aren't immediately needed
• Be cautious of memory usage when creating multiple blocs

Back to Portfolio