React Redux疑问：在Reducer中添加异步方法是否属于反模式？

嘿，刚接触React Native/Redux很正常，这个问题其实是很多新手都会疑惑的点，我来给你捋清楚～

首先得明确Redux的核心规则之一：Reducer必须是纯函数。什么是纯函数？就是给定相同的输入（state和action），必须返回完全相同的输出，而且不能有任何副作用——包括异步操作、修改传入的state、调用外部API、操作设备API（比如你说的本地通知）这些都属于副作用范畴。

为什么Reducer里写异步不可行？ #

虽然你现在可能运行起来没报错，但这种做法会埋下很多隐患：

• 状态不可预测：异步操作的完成时间是不确定的，比如你触发了一个异步方法，可能在状态已经更新好几次之后，这个异步操作才完成并修改state，导致状态混乱，很难排查问题。
• 调试困难：Redux DevTools本来能完美追踪每一次state的变化，但异步操作在Reducer里执行的话，DevTools无法记录异步流程的中间状态，调试起来会非常头疼。
• 测试成本高：纯函数的测试非常简单，只需要输入对应参数看输出就行，但带异步的Reducer需要mock大量外部依赖，测试逻辑会变得复杂。
• 竞态条件风险：如果多个异步操作同时修改同一个state，很容易出现竞态问题，比如两个异步请求先后返回，覆盖了彼此的结果，这种bug很难定位。

那中间件是不是必须的？ #

没错，处理异步/副作用操作，中间件是Redux官方推荐的标准方式。你觉得中间件带来很多样板代码，其实是因为可能还没用到简化工具——现在官方主推的Redux Toolkit已经把大部分样板代码都封装好了，比如createAsyncThunk可以轻松处理异步逻辑，完全不用自己写复杂的中间件配置。

举个简单的例子，用Redux Toolkit处理本地通知的异步逻辑：

// 首先创建异步thunk
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit';

export const showLocalNotification = createAsyncThunk(
  'notifications/show',
  async (notificationData, { rejectWithValue }) => {
    try {
      // 这里写你的设备API异步操作，比如调用本地通知的方法
      await DeviceNotifications.show(notificationData);
      return notificationData;
    } catch (error) {
      return rejectWithValue(error.message);
    }
  }
);

// 然后在slice里处理异步的三个状态：pending/fulfilled/rejected
const notificationsSlice = createSlice({
  name: 'notifications',
  initialState: {
    isLoading: false,
    error: null,
    lastNotification: null,
  },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(showLocalNotification.pending, (state) => {
        state.isLoading = true;
        state.error = null;
      })
      .addCase(showLocalNotification.fulfilled, (state, action) => {
        state.isLoading = false;
        state.lastNotification = action.payload;
      })
      .addCase(showLocalNotification.rejected, (state, action) => {
        state.isLoading = false;
        state.error = action.payload;
      });
  },
});

export default notificationsSlice.reducer;

你看，这样的代码既规范，又没有太多冗余的样板，还能完美追踪状态变化。

总结 #

虽然一开始觉得中间件麻烦，但从项目长期维护、状态可预测性、调试便利性这些角度来看，它是必要的。而且现在Redux Toolkit已经把复杂度大大降低了，完全不用再写传统Redux那种繁琐的action types、action creators、纯Reducer的样板代码。

建议你尽快迁移到Redux Toolkit的写法，避免在Reducer里写异步操作，不然以后项目变大了，会遇到很多难以解决的问题。

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