为何Flow会拒绝此React Context+useReducer的实现方案？

Hey there! Your code runs correctly, but those Flow warnings aren't because of a mistake in your logic—they're a result of how Flow handles union types when all the subtypes share the same type tag. Let me break this down for you and share fixes.

Why the warnings pop up #

You’ve defined SessionAction as a union of three subtypes, but all three use the exact same type value: UPDATE_SESSION_PROP. Flow relies on distinct tag values (the type field here) to narrow down union types. When every subtype has the same tag, Flow can’t tell which specific action it’s dealing with.

From Flow’s perspective, action.propName could be any of the three property names, and action.payload could be either a string or number. It’s worried you might accidentally assign a number to currentCompanyName (which expects a string) or vice versa—even though your action definitions prevent that in practice.

Solution 1: Use unique type values (Recommended) #

This is the standard best practice for useReducer/Redux-style state management. Giving each action a unique type lets Flow easily narrow the union type, eliminating the warnings and making your code more readable.

Here’s how to adjust your code:

First, update your action types to have unique type values:

export type UserEmailAction = {type: 'UPDATE_USER_EMAIL', payload: string};
export type UserAccessLevelAction = {type: 'UPDATE_ACCESS_LEVEL', payload: number};
export type CurrentCompanyNameAction = {type: 'UPDATE_COMPANY_NAME', payload: string};

export type SessionAction = | UserEmailAction | UserAccessLevelAction | CurrentCompanyNameAction;

Then modify your reducer to handle each unique type:

export const sessionReducer = (state: SessionState, action: SessionAction) => {
  switch (action.type) {
    case 'UPDATE_USER_EMAIL': {
      return { ...state, currentUserEmail: action.payload };
    }
    case 'UPDATE_ACCESS_LEVEL': {
      return { ...state, currentUserAccessLevel: action.payload };
    }
    case 'UPDATE_COMPANY_NAME': {
      return { ...state, currentCompanyName: action.payload };
    }
    default: {
      return state;
    }
  }
}

This approach not only fixes the Flow warnings but also makes your code more explicit—anyone reading it can immediately see what each action does without having to check the propName.

Solution 2: Keep the shared type with type assertions/guards #

If you really want to stick with a single UPDATE_SESSION_PROP type, you can help Flow narrow the union with type assertions or custom type guards.

Option A: Type Assertion

You can assert that the payload matches the type expected by the target property:

export const sessionReducer = (state: SessionState, action: SessionAction) => {
  switch (action.type) {
    case UPDATE_SESSION_PROP: {
      return { 
        ...state, 
        [action.propName]: action.payload as $PropertyType<SessionState, typeof action.propName> 
      };
    }
    default: {
      return state;
    }
  }
}

Option B: Custom Type Guards

Write small helper functions to let Flow know which action subtype it’s dealing with:

function isUserEmailAction(action: SessionAction): action is UserEmailAction {
  return action.propName === 'currentUserEmail';
}

function isUserAccessLevelAction(action: SessionAction): action is UserAccessLevelAction {
  return action.propName === 'currentUserAccessLevel';
}

function isCurrentCompanyNameAction(action: SessionAction): action is CurrentCompanyNameAction {
  return action.propName === 'currentCompanyName';
}

export const sessionReducer = (state: SessionState, action: SessionAction) => {
  switch (action.type) {
    case UPDATE_SESSION_PROP: {
      if (isUserEmailAction(action)) {
        return { ...state, currentUserEmail: action.payload };
      } else if (isUserAccessLevelAction(action)) {
        return { ...state, currentUserAccessLevel: action.payload };
      } else if (isCurrentCompanyNameAction(action)) {
        return { ...state, currentCompanyName: action.payload };
      }
      return state;
    }
    default: {
      return state;
    }
  }
}

That said, this adds extra boilerplate, so Solution 1 is almost always the better choice for maintainability and clarity.

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