Redux TypeScript Patterns

Type Redux state, actions, thunks, and hooks with full inference and minimal manual annotation

When to Use

• Setting up TypeScript types for a Redux Toolkit project
• Fixing type errors in slices, thunks, or connected components
• Adding type safety to

  useDispatch

  and

  useSelector

• Typing

  extraReducers

  ,

  createAsyncThunk

  , or middleware

Instructions

1. Infer

   RootState

   and

   AppDispatch

   from the store — never define them manually.
2. Create typed hooks once (

   useAppDispatch

   ,

   useAppSelector

   ) and use them everywhere.
3. Use

   PayloadAction<T>

   for reducer parameter types. RTK infers the rest from

   createSlice

   .
4. Type

   createAsyncThunk

   with three generic arguments:

   <ReturnType, ArgType, ThunkApiConfig>

   .
5. In

   extraReducers

   , use the builder callback — it provides full type inference for each case.
6. Use

   isRejectedWithValue

   type guard for narrowing rejection payloads.
7. Avoid

   as

   type assertions in reducers — if you need them, the type definition is wrong.

// store/index.ts — inferred types
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

// Typed hooks — use throughout the app
export const useAppDispatch: () => AppDispatch = useDispatch;
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;

// Typed createAsyncThunk
interface FetchError {
  message: string;
  code: number;
}

export const fetchUser = createAsyncThunk<
  User,                                    // Fulfilled return type
  string,                                  // Argument type (userId)
  { state: RootState; rejectValue: FetchError }  // ThunkAPI config
>(
  'users/fetch',
  async (userId, { rejectWithValue }) => {
    const res = await fetch(`/api/users/${userId}`);
    if (!res.ok) {
      return rejectWithValue({ message: 'Not found', code: res.status });
    }
    return res.json();
  }
);

// extraReducers with full inference
extraReducers: (builder) => {
  builder
    .addCase(fetchUser.fulfilled, (state, action) => {
      // action.payload is User (inferred)
      state.currentUser = action.payload;
    })
    .addCase(fetchUser.rejected, (state, action) => {
      if (action.payload) {
        // action.payload is FetchError (from rejectWithValue)
        state.error = action.payload.message;
      } else {
        // action.error is SerializedError (thrown exception)
        state.error = action.error.message ?? 'Unknown error';
      }
    });
},

Details

ThunkAPI config object: Pass

{ state: RootState; rejectValue: T; dispatch: AppDispatch }

as the third generic to

createAsyncThunk

. This types

getState()

,

rejectWithValue()

, and

dispatch()

inside the payload creator.

Middleware typing: Custom middleware receives

MiddlewareAPI<AppDispatch, RootState>

:

const logger: Middleware<{}, RootState> = (storeApi) => (next) => (action) => {
  console.log('dispatching', action);
  return next(action);
};

Entity adapter typing: Pass the entity type to

createEntityAdapter<User>()

. The adapter methods and selectors are fully typed from this.

Common type errors and fixes:

• Property does not exist on type

  in

  getState()

  — add

  state: RootState

  to the thunk config

• Argument not assignable to PayloadAction

  — check that the action creator's prepare callback return type matches

• Type instantiation is excessively deep

  — usually from circular slice imports; break the cycle with a shared types file

• Cannot use namespace as type

  — import types with

  import type

  to avoid circular dependencies

RTK 2.0 changes:

Tuple

replaces arrays for middleware.

combineSlices

provides automatic type inference for lazy-loaded slices. The

reducer

field in

configureStore

accepts a

combineSlices

result directly.

Source

https://redux-toolkit.js.org/usage/usage-with-typescript

Process

1. Read the instructions and examples in this document.
2. Apply the patterns to your implementation, adapting to your specific context.
3. Verify your implementation against the details and edge cases listed above.

Harness Integration

• Type: knowledge — this skill is a reference document, not a procedural workflow.
• No tools or state — consumed as context by other skills and agents.

Success Criteria

• The patterns described in this document are applied correctly in the implementation.
• Edge cases and anti-patterns listed in this document are avoided.