Flutter+Redux/AsyncRedux中如何解耦组件与AppState并实现复用？

Great question! Tight coupling between your Redux-connected components and a specific AppState is a common pain point when trying to reuse components across different Flutter apps. Let’s walk through practical patterns to fix this and make your components truly reusable:

1. Define Abstract Contracts for State Dependencies #

Instead of having your component depend directly on AppState, create an abstract interface that describes only the state properties your component needs. Then, have each app's unique AppState implement this interface. This way, your component only cares about the contract, not the full state structure.

Example: #

// Step 1: Define the contract your component needs
abstract class UserStateContract {
  User get currentUser;
  bool get isUserLoggedIn;
}

// Step 2: Make each app's AppState implement the contract
class AppStateAppA implements UserStateContract {
  @override
  final User currentUser;
  @override
  final bool isUserLoggedIn;
  
  // AppA-specific state fields
  final ThemeMode activeTheme;
}

class AppStateAppB implements UserStateContract {
  @override
  final User currentUser;
  @override
  final bool isUserLoggedIn;
  
  // AppB-specific state fields
  final CartState userCart;
}

// Step 3: Build your component to depend on the contract
class UserProfileWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StoreConnector<dynamic, UserStateContract>(
      converter: (store) => store.state as UserStateContract,
      builder: (context, userState) {
        if (!userState.isUserLoggedIn) {
          return const Text("Please log in to view your profile");
        }
        return Column(
          children: [
            Text("Welcome, ${userState.currentUser.fullName}"),
            // Rest of your profile UI
          ],
        );
      },
    );
  }
}

This component will work seamlessly with both AppStateAppA and AppStateAppB as long as they implement the UserStateContract.

2. Use ViewModels and Injected Converters #

Take decoupling a step further by creating a ViewModel that holds exactly the data your component needs to render. Then, let each app provide its own converter function that maps its AppState to this ViewModel. The component never interacts with AppState directly—it only receives the ViewModel.

Example: #

// Step 1: Define a ViewModel for your component
class UserProfileViewModel {
  final String userName;
  final bool isLoggedIn;

  UserProfileViewModel({required this.userName, required this.isLoggedIn});
}

// Step 2: Build a reusable component that accepts a converter
class UserProfileWidget extends StatelessWidget {
  final UserProfileViewModel Function(Store) stateConverter;

  const UserProfileWidget({
    Key? key,
    required this.stateConverter,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return StoreConnector<dynamic, UserProfileViewModel>(
      converter: stateConverter,
      builder: (context, vm) {
        if (!vm.isLoggedIn) {
          return const Text("Please log in");
        }
        return Text("Welcome, ${vm.userName}");
      },
    );
  }
}

// Step 3: Use the component in AppA
UserProfileWidget(
  stateConverter: (store) {
    AppStateAppA state = store.state as AppStateAppA;
    return UserProfileViewModel(
      userName: state.currentUser.fullName,
      isLoggedIn: state.isUserLoggedIn,
    );
  },
)

// Step 4: Use the same component in AppB
UserProfileWidget(
  stateConverter: (store) {
    AppStateAppB state = store.state as AppStateAppB;
    return UserProfileViewModel(
      userName: state.currentUser.displayName,
      isLoggedIn: state.isUserLoggedIn,
    );
  },
)

This pattern makes your component completely agnostic to the app's state structure—you just adapt the converter for each app.

3. Leverage AsyncRedux's VmFactory Abstraction (If Using AsyncRedux) #

If you're using async_redux, its VmFactory system is designed to help with this kind of decoupling. You can create abstract state slices and tie your ViewModel to those slices instead of the full AppState.

Example: #

// Step 1: Define an abstract state slice
abstract class UserSlice {
  User get user;
  bool get isLoggedIn;
}

// Step 2: Include the slice in each app's AppState
class AppStateAppA {
  final UserSlice userSlice;
  final ThemeMode activeTheme;
}

class AppStateAppB {
  final UserSlice userSlice;
  final CartState userCart;
}

// Step 3: Create a ViewModel for your component
class UserProfileVm extends Vm {
  final String userName;
  final bool isLoggedIn;

  UserProfileVm({required this.userName, required this.isLoggedIn}) 
    : super(equals: [userName, isLoggedIn]);
}

// Step 4: Build a reusable component with a flexible VmFactory
class UserProfileWidget extends StatelessWidget {
  final VmFactory<dynamic, UserProfileWidget> vmFactory;

  const UserProfileWidget({
    Key? key,
    required this.vmFactory,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return StoreConnector<dynamic, UserProfileVm>(
      vm: () => vmFactory,
      builder: (context, vm) {
        // Render your UI using the ViewModel
      },
    );
  }
}

// Step 5: Create app-specific VmFactories
class UserProfileVmFactoryAppA extends VmFactory<AppStateAppA, UserProfileWidget> {
  @override
  UserProfileVm fromStore() {
    return UserProfileVm(
      userName: state.userSlice.user.fullName,
      isLoggedIn: state.userSlice.isLoggedIn,
    );
  }
}

class UserProfileVmFactoryAppB extends VmFactory<AppStateAppB, UserProfileWidget> {
  @override
  UserProfileVm fromStore() {
    return UserProfileVm(
      userName: state.userSlice.user.displayName,
      isLoggedIn: state.userSlice.isLoggedIn,
    );
  }
}

4. Split Components into UI and Container Layers #

A tried-and-true approach is to separate your component into two parts:

• A pure UI component: Stateless, receives all necessary data via props, no Redux dependencies.
• A container component: Handles connecting to the Redux store, maps AppState to the UI component's props.

Example: #

// Pure UI component (fully reusable across apps)
class UserProfileUI extends StatelessWidget {
  final String userName;
  final bool isLoggedIn;

  const UserProfileUI({
    Key? key,
    required this.userName,
    required this.isLoggedIn,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    if (!isLoggedIn) {
      return const Text("Please log in");
    }
    return Text("Welcome, $userName");
  }
}

// AppA-specific container component
class UserProfileContainerAppA extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StoreConnector<AppStateAppA, _ViewModel>(
      converter: (store) => _ViewModel(
        userName: store.state.currentUser.fullName,
        isLoggedIn: store.state.isUserLoggedIn,
      ),
      builder: (context, vm) => UserProfileUI(
        userName: vm.userName,
        isLoggedIn: vm.isLoggedIn,
      ),
    );
  }

  class _ViewModel {
    final String userName;
    final bool isLoggedIn;

    _ViewModel({required this.userName, required this.isLoggedIn});
  }
}

// AppB-specific container component
class UserProfileContainerAppB extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return StoreConnector<AppStateAppB, _ViewModel>(
      converter: (store) => _ViewModel(
        userName: store.state.currentUser.displayName,
        isLoggedIn: store.state.isUserLoggedIn,
      ),
      builder: (context, vm) => UserProfileUI(
        userName: vm.userName,
        isLoggedIn: vm.isLoggedIn,
      ),
    );
  }

  class _ViewModel {
    final String userName;
    final bool isLoggedIn;

    _ViewModel({required this.userName, required this.isLoggedIn});
  }
}

The UserProfileUI component is now 100% reusable—you just create a new container for each app's state.

Best Practices #

• Keep dependencies minimal: Only expose the state properties your component absolutely needs, not the entire AppState.
• Test in isolation: Pure UI components are easy to test with mock props, without needing a Redux store.
• Avoid business logic in components: Keep state mapping and business logic in converters, VmFactories, or containers—components should only handle rendering.

内容的提问来源于stack exchange，提问作者Marcelo Glasberg