能否根据state.propertyC值用同一Reducer更新state.propertyA/B？是否符合最佳实践？

我有一个Reducer，希望根据state.propertyC的值来决定更新state.propertyA还是state.propertyB，示例代码如下：

const conditionalReducer: CaseReducer<StateType, PayloadActionType> = (state, action) => {
    if(state.propertyC === true) {
        state.propertyA = action.payload;
    } else {
        state.propertyB = action.payload;
    }
}

请问这种做法是否属于最佳实践？还是应该编写两个独立的Reducer，在决定调用哪个Action前先处理条件逻辑？

我在应用中还使用了thunk中间件，想了解是否有结合它的更优方案。

一、你的写法是否符合最佳实践？ #

这种写法本身合法可运行，但算不上Redux的最佳实践——核心原因是它违背了Redux的「单一职责」和「可预测性」原则：

• 单一职责：这个Reducer同时处理两个不同的状态更新逻辑，后续若propertyA或propertyB的更新规则需要单独调整，得在同一个函数里修改，增加了维护复杂度。
• 可预测性：Action的语义变得模糊。原本一个Action应该对应明确的状态变更意图，但现在同一个Action可能触发两种不同的更新，调试时需要额外查看propertyC的值才能理清流程。

二、更优的基础方案：拆分Action与Reducer #

建议把逻辑拆分到Action触发前，而非Reducer内部：

1. 编写两个独立的Case Reducer，分别负责更新propertyA和propertyB：

const updatePropertyA: CaseReducer<StateType, PayloadActionType> = (state, action) => {
    state.propertyA = action.payload;
};

const updatePropertyB: CaseReducer<StateType, PayloadActionType> = (state, action) => {
    state.propertyB = action.payload;
};

2. 在创建Slice时，给两个Reducer绑定对应的Action：

const mySlice = createSlice({
    name: 'mySlice',
    initialState,
    reducers: {
        updatePropertyA,
        updatePropertyB
    }
});

export const { updatePropertyA, updatePropertyB } = mySlice.actions;

3. 在组件或业务逻辑中，先判断propertyC的值，再调用对应的Action：

// 组件内或逻辑层
const handleUpdate = (payload) => {
    const currentPropertyC = store.getState().mySlice.propertyC;
    if (currentPropertyC) {
        dispatch(updatePropertyA(payload));
    } else {
        dispatch(updatePropertyB(payload));
    }
};

三、结合Thunk中间件的优化方案 #

如果判断逻辑需要依赖异步数据，或者不想把判断逻辑暴露在组件里，可以用Thunk封装这个条件判断：

export const updateTargetProperty = (payload) => (dispatch, getState) => {
    const { propertyC } = getState().mySlice;
    if (propertyC) {
        dispatch(updatePropertyA(payload));
    } else {
        dispatch(updatePropertyB(payload));
    }
};

之后在组件里直接调用这个Thunk即可，无需关心内部的条件判断：

// 组件内
dispatch(updateTargetProperty(payload));

这种方式的好处是：

• 把条件判断逻辑封装在业务层，组件只需要关心「触发更新」这个动作，不用处理状态判断细节
• 如果后续需要修改判断规则（比如加入异步请求获取判断条件），只需要修改Thunk函数，不影响组件和Reducer

总结 #

Reducer里的条件判断不是绝对禁止，但拆分Action+在Thunk/逻辑层处理条件的方式，更符合Redux的设计理念，也让代码更易维护、更具可预测性。

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