Redux reducer中调用其他reducer是否为不良实践？

回答 #

直接在reducer中调用其他case reducer不属于最佳实践，核心问题在于：

• 破坏单一职责：每个case reducer本应只处理对应action的状态更新，互相调用会导致逻辑深度耦合，后续维护、排查问题难度陡增。
• 调试障碍：Redux DevTools仅会显示触发的初始action，但实际状态更新是多个reducer调用的结果，无法清晰追踪每一步的状态变化路径。
• 行为不透明：这种嵌套调用会让reducer的状态更新逻辑变得隐晦，其他开发者难以快速理解状态变化的完整流程。

下面逐个分析你的可选方案：

方案1：维持现有写法

• 优势：无需改动现有代码，短期实现成本低。
• 劣势：耦合、调试困难等问题会持续存在，随着业务逻辑复杂化，维护成本会越来越高。

方案2：将逻辑提取到Thunks中（推荐）

这是最适配你场景的方案，把条件判断和多步骤状态更新逻辑转移到thunk，让reducer只负责单一的状态原子操作：

• 改造步骤：
  1. 简化reducer，让每个case reducer只做单一状态更新：

     export const game = createSlice({
       name: 'game',
       initialState,
       reducers: {
         incrementScale: (state) => {
           state.currentScale = state.scales.pop()
         },
         incrementNote: (state) => {
           state.currentNote = state.notes.shift()
           state.triesLeft = INTIAL_TRIES
         },
         setGameInProgress: (state, action) => {
           state.isGameInProgress = action.payload
         }
       }
     })
     

  2. 编写thunk处理条件判断和多步骤dispatch：

     export const incrementNoteThunk = () => (dispatch, getState) => {
       dispatch(game.actions.incrementNote());
       const { game } = getState();
       
       // 无剩余note时触发scale更新
       if (!game.currentNote) {
         dispatch(game.actions.incrementScale());
         const updatedGame = getState().game;
         // 无剩余scale时结束游戏
         if (!updatedGame.currentScale) {
           dispatch(game.actions.setGameInProgress(false));
         }
       }
     };
     

  3. 在自定义hook中调用thunk，同时加入日志、后端调用等副作用：

     export function useGame() {
       const dispatch = useDispatch();
       
       const handleIncrementNote = async () => {
         // 日志记录
         console.log('执行incrementNote操作');
         try {
           // 后端调用（按需添加）
           // await fetch('/api/game/action', { method: 'POST' });
           dispatch(incrementNoteThunk());
         } catch (error) {
           console.error('操作失败:', error);
         }
       };
       
       return { handleIncrementNote };
     }
     

• 优势：
  • reducer保持单一职责，逻辑清晰，易于维护和调试。
  • 条件判断、多步骤逻辑集中在thunk，与状态更新逻辑分离。
  • 自定义hook可方便封装副作用逻辑，不会污染纯函数性质的reducer。

方案3：用Selectors计算派生数据

该方案不适合你的场景。Selectors的核心作用是从现有状态中提取、计算派生数据，无法主动触发状态更新，因此无法替代你当前需要的条件判断与状态流转逻辑。

总结 #

优先选择方案2，将多步骤逻辑迁移到thunk中，让reducer回归单一职责，同时利用自定义hook封装副作用与dispatch调用。这种结构符合Redux最佳实践，代码可读性、可维护性会大幅提升。

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