Flutter开发中BLoC最佳实践：单屏一个还是单区域一个？

Hey there! Let's tackle your problem head-on—dealing with two independent dynamic regions on the same screen using Flutter Bloc, where a single Bloc is causing unwanted simultaneous refreshes. Here's a breakdown of both approaches and my recommendation based on best practices:

Option 1: Optimize a Single Bloc with Granular State Design #

If you prefer keeping logic centralized (or if the two regions have subtle business ties), you can fix the refresh issue by splitting your Bloc state into smaller, independent sub-states, then using buildWhen to control which UI parts rebuild.

How to implement this: #

• Split your main screen state into distinct sub-states for each region. For example:

  class HomeScreenState extends Equatable {
    final UserProfileState userProfile;
    final RecentOrdersState recentOrders;
  
    const HomeScreenState({
      required this.userProfile,
      required this.recentOrders,
    });
  
    @override
    List<Object> get props => [userProfile, recentOrders];
  
    HomeScreenState copyWith({
      UserProfileState? userProfile,
      RecentOrdersState? recentOrders,
    }) {
      return HomeScreenState(
        userProfile: userProfile ?? this.userProfile,
        recentOrders: recentOrders ?? this.recentOrders,
      );
    }
  }
  
  // Example sub-state for one region
  enum UserProfileStatus { initial, loading, loaded, error }
  class UserProfileState extends Equatable {
    final UserProfileStatus status;
    final User? userData;
  
    const UserProfileState({required this.status, this.userData});
  
    @override
    List<Object?> get props => [status, userData];
  }
  

• In your UI, use BlocBuilder with the buildWhen parameter to only rebuild when the relevant sub-state changes:

  // User Profile Region
  BlocBuilder<HomeScreenBloc, HomeScreenState>(
    buildWhen: (prev, curr) => prev.userProfile != curr.userProfile,
    builder: (context, state) {
      switch (state.userProfile.status) {
        case UserProfileStatus.loading:
          return const CircularProgressIndicator();
        case UserProfileStatus.loaded:
          return UserProfileCard(user: state.userProfile.userData!);
        default:
          return const SizedBox.shrink();
      }
    },
  ),
  
  // Recent Orders Region
  BlocBuilder<HomeScreenBloc, HomeScreenState>(
    buildWhen: (prev, curr) => prev.recentOrders != curr.recentOrders,
    builder: (context, state) {
      // Render orders based on recentOrders sub-state
    },
  )
  

Pros & Cons: #

• Pros: Centralized logic, no extra Bloc lifecycle management, works if regions share business logic (e.g., a filter that affects both).
• Cons: State structure gets more complex; if regions are truly independent, your Bloc can become bloated with unrelated logic over time.

Option 2: Use Separate Blocs for Each Region #

This is my go-to recommendation for truly independent regions—it aligns perfectly with the Single Responsibility Principle and eliminates unwanted refreshes at the source.

How to implement this: #

• Create two distinct Blocs (e.g., UserProfileBloc and RecentOrdersBloc), each handling their own events, states, and business logic.
• Provide both Blocs to your screen (via MultiBlocProvider if needed), then use BlocBuilder for each region with its corresponding Bloc:

  MultiBlocProvider(
    providers: [
      BlocProvider(create: (context) => UserProfileBloc(userRepository)),
      BlocProvider(create: (context) => RecentOrdersBloc(orderRepository)),
    ],
    child: const HomeScreen(),
  )
  
  // In HomeScreen's build method
  BlocBuilder<UserProfileBloc, UserProfileState>(
    builder: (context, state) {
      // Render user profile
    },
  ),
  BlocBuilder<RecentOrdersBloc, RecentOrdersState>(
    builder: (context, state) {
      // Render recent orders
    },
  )
  

Pros & Cons: #

• Pros: Clean, modular code; each Bloc only cares about its own region, making testing and maintenance easier; no risk of unintended refreshes since regions listen to separate state streams.
• Cons: Requires managing multiple Blocs (though Flutter Bloc's provider system makes this trivial); if regions need to communicate later, you’ll need to add event coordination (e.g., via a shared repository or parent widget).

Final Recommendation #

Since you mentioned the two regions are independent, go with separate Blocs. It’s a cleaner, more scalable approach that avoids the complexity of granular state management for unrelated logic. If you later need cross-region interactions, you can handle that with shared repositories (where Blocs listen to data changes) or by dispatching events between Blocs via the context.

内容的提问来源于stack exchange，提问作者Pittawat Taveekitworachai