如何在Redux Toolkit的createSlice中复用Reducer逻辑？

Great question! You're right to want to avoid repeating that state update logic across multiple async thunks—keeping code DRY is key to maintainable Redux apps. Let's break down a few solid approaches to solve this:

1. Call your slice's case reducers directly #

The reducers you define in createSlice are exposed as functions under slice.caseReducers. Since they're pure functions that take state and an action, you can invoke them directly inside your extraReducers callbacks:

builder.addCase(getUserInfo.pending, (state) => {
  // Call the setShowProgress reducer with a payload of true
  userSlice.caseReducers.setShowProgress(state, { 
    type: '', // Type doesn't matter here since the reducer doesn't use it
    payload: true 
  });
  // Call clearError to reset error state
  userSlice.caseReducers.clearError(state, { type: '' });
})

This works because Redux Toolkit's createSlice generates these case reducer functions explicitly, so you can reuse them wherever you have access to the slice and the state.

2. Extract reusable state update utilities (Recommended) #

For even cleaner code, pull the state update logic out into standalone pure functions. This way, both your slice reducers and extraReducers can reference the same logic, making it easy to update later if your state shape changes:

// Reusable state update functions
const updateShowProgress = (state, isVisible) => {
  state.showProgress = isVisible;
};

const resetErrorState = (state) => {
  state.error = null;
  state.errorMessage = null;
};

// Then in your slice:
const userSlice = createSlice({
  name: 'user',
  initialState,
  reducers: {
    setShowProgress(state, action: PayloadAction<boolean>) {
      updateShowProgress(state, action.payload);
    },
    clearError(state) {
      resetErrorState(state);
    }
  },
  extraReducers: builder => {
    builder.addCase(getUserInfo.pending, (state) => {
      updateShowProgress(state, true);
      resetErrorState(state);
    })
    // ... handle fulfilled/rejected
  }
})

This is my preferred approach because it centralizes your state mutation logic. If you ever need to adjust how showProgress or error state is updated, you only change it in one place instead of hunting through multiple reducers/thunks.

3. Dispatch actions from inside the async thunk #

Another option is to handle these state updates directly in your createAsyncThunk function using thunkApi.dispatch. This moves the state management logic into the thunk itself, which can make the flow more explicit:

export const getUserInfo = createAsyncThunk('user/get', async (userId, thunkApi) => {
  // Dispatch actions at the start of the thunk
  thunkApi.dispatch(userSlice.actions.setShowProgress(true));
  thunkApi.dispatch(userSlice.actions.clearError());

  try {
    const response = await fetchUserApi(userId);
    // Hide progress when done
    thunkApi.dispatch(userSlice.actions.setShowProgress(false));
    return response.data;
  } catch (err) {
    thunkApi.dispatch(userSlice.actions.setShowProgress(false));
    return thunkApi.rejectWithValue(err.message);
  }
})

With this approach, you don't need to handle pending in extraReducers for these state changes. Just be aware that if you have multiple thunks that need this same "start loading + clear error" logic, you'll want to wrap this pattern in a reusable helper function to avoid repetition.

Quick note on why you can't "dispatch" in extraReducers #

Just to clarify: You can't use dispatch inside extraReducers callbacks because those are reducer functions—their only job is to take the current state and an action, and return (or mutate via Immer) the new state. Dispatching actions is a side effect, which doesn't belong in reducers.

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