So, there is a long-standing TypeScript & Redux pattern of creating a union RootAction
type that contains all your application's action types. Sometimes, you would also create a lot of reducer-specific sub-unions.
I think that this has always been a crutch - and given the options we have today, it's most likely an antipattern.
So let's look at why it was used, where it was used and what you can use instead.
Classically, these action union types were created to use the Discriminating Union pattern.
This allowed you to do something like write a reducer like
const actionType1 = 'a'
const actionType2 = 'b'
type ActionA = { type: typeof actionType1; payload: { value: string } }
type ActionB = { type: typeof actionType2; payload: { value: number } }
type State = {}
type Actions = ActionA | ActionB
function reducer(state: State, action: Actions): State {
switch (action.type) {
case actionType1:
return { ...state /* action.payload.value is inferred correctly here */ }
case actionType2:
return { ...state /* action.payload.value is inferred correctly here */ }
}
return state
}
In a world where switch
...case
reducers were the norm anyways, this seemed like a very handy pattern. It required a little extra work, like collecting all actions together in a central place and defining all those type
constants, but those type
constants were already defined anyways and due to all that boilerplate, building an extra union type didn't seem so bad.
There is a point about the discriminated union pattern that was missed though: A discriminated union has to be complete for it to work. Otherwise, you will hide errors.
In this specific case, it starts with a lie to the compiler: we're telling tsc
that this reducer function will only ever be called with an action that is a member of the Actions
union.
But is it really? No, this reducer will be called by every action that is ever being dispatched in our application. So if we were only combining the action types we cared about, we'd already be lost. But what if we really went thorougly through the whole app, putting every single action type into that union?
It would still be incomplete.
Your application is not the only source of actions.
There's also middleware, popular examples being "connected-react-router" which for example dispatched a '@@router/LOCATION_CHANGE'
-typed action or redux-persist, which will dispatch a 'persist/REHYDRATE'
-typed action.
And even if you went through all middlewares and also added their action types to the union, you'd still be missing the redux-internal 'INIT'
action. Well, let's just add that. Want to know a fun fact about INIT
? In development mode, that action name is randomized to prevent developers from relying on that redux internal.
Bottom line? Your Actions
type will never be complete, no matter how hard you try.
So having accepted that, we'll probably do what most people (and, at this time, even the redux documentation on TypeScript) do and just create smaller sub-types, one small union for all actions we want to handle in a specific reducer. So, like in our example above, that type might even only contain two action types. Let's assume it does.
What bugs are actually hidden by that little oversimplification?
Let's take our reducer from above and just remove that last return statement.
function reducer(state: State, action: Actions): State {
switch (action.type) {
case actionType1:
return { ...state, /* action.prop1 is inferred correctly here */ }
case actionType2:
return { ...state, /* action.prop2 is inferred correctly here */ }
}
- return state;
}
This is definitely a bug. This reducer will now return undefined
in case of that INIT
action we discussed above. But TypeScript won't notice. TypeScript assumes that this method will only ever be called with one of two action types - and both of these are handled. Because we are working on what seems (but really is not) a discriminated union here, union exhaustiveness checking kicks in and assumes that there will never any other return path and that this function will always return a State
object.
Which it obviously does not.
Also, did you notice that all actions in our union have a action.payload.value
property? TypeScript will now allow us to directly access that property without any additional checks - after all, it will always be there - surely this method won't be called with any other action.
Except for a lot of other actions. And at least that INIT
type has no payload
property, so we're just one execution of our app away from the runtime error message
Uncaught TypeError: action.payload is undefined
Of course, all that doesn't seem too bad. You'll surely remember that you lied there and take all possible precautions that none of those above bugs happen. But will you really, a year or two down the line? Will a new team member that's just getting onboarded and is not used to your little redux-lies yet?
You're deliberately disabling TypeScript there, but it is not visible to anyone who doesn't know the pattern. If you were any
-casting, at least that would be visible. Here it's not. Don't do that if there are other ways to do the same.
But are there?
The correct tool for this use case has been around for a long type: Type predicate functions.
A naive variation of a type guard function would look like this:
import { AnyAction } from 'redux'
interface SpecificAction extends AnyAction {
type: 'somethingSpecific'
payload: string
}
function matchSpecificAction(action: AnyAction): action is SpecificAction {
return action.type === 'somethingSpecific'
}
function doSomething(action: AnyAction) {
if (matchSpecificAction(action)) {
action.payload // this is correctly inferred to `string` here
}
}
Of course, this does seem to be a lot of code when writing it by hand - but it can be automated. And it can be automated a lot better than manually having to combine action types.
If you are using redux toolkit, all your action creators created by createAction
and createSlice
will already have such a type guard:
import { createAction } from '@reduxjs/toolkit'
import { AnyAction } from 'redux'
const myAction = createAction<{ value: string }>('my/action')
function doSomething(action: AnyAction) {
if (myAction.match(action)) {
action.payload.value // this is correctly inferred to `string` here
}
}
and if you are not using redux toolkit, you could for example use this helper function that attaches a .match(action)
function and a .type
property to every action creator you pass into it:
import { AnyAction } from 'redux'
type Matchable<AC extends () => AnyAction> = AC & {
type: ReturnType<AC>['type']
match(action: AnyAction): action is ReturnType<AC>
}
function withMatcher<AC extends () => AnyAction>(
actionCreator: AC
): Matchable<AC>
function withMatcher<
AC extends (...args: any[]) => AnyAction & { type: string }
>(actionCreator: AC): Matchable<AC>
function withMatcher<AC extends (...args: any[]) => AnyAction>(
actionCreator: AC,
type: ReturnType<AC>['type']
): Matchable<AC>
function withMatcher(
actionCreator: Function & { type?: string },
_type?: string
) {
const type = _type ?? actionCreator.type ?? actionCreator().type
return Object.assign(actionCreator, {
type,
match(action: AnyAction) {
return action.type === type
}
})
}
Now you can just wrap your action creator in withMatcher
and use it like in the example above!
const createActionA = withMatcher((payload?: string) => {
return {
type: 'foo/bar',
payload
}
})
Why the additional type
you ask? That might come in handy when we talk about redux-saga
later ;)
With all this, your Reducer<MyState, MyActions>
lie to the compiler becomes a valid Reducer<State, AnyAction>
and will probably look something like this:
function reducer(state: MyState, action: AnyAction): MyState {
if (specificAction.match(action)) {
return { ...state /* action is correctly inferred here */ }
}
if (anotherAction.match(action)) {
return { ...state /* action is correctly inferred here */ }
}
return state
}
The bugs from above? Don't apply any more.
Of course, you can reduce that down quite a bit using createReducer
or createSlice
from @reduxjs/toolkit
, which is the official recommendation and which you really should be using.
With createSlice
, it would look like this:
const slice = createSlice({
name: 'counter',
initialState: { value: 0 },
reducer: {
// will result in an action of type `counter/increment`
increment(state) {
// state values can be modified mutably thanks to `immer` integration
state.value++
},
incrementBy(state, { payload }: PayloadAction<number>) {
state.value += payload
}
}
})
export const { increment, incrementBy } = slice.actions // automatically generated action creators with correct types
export default slice.reducer
No matter what you use, your reducers should be covered now. No more lie to the compiler, no more collection type definitions over multiple files in a central location and creating unwieldy unions.
Of course, that union type was used in several patterns with other libraries & use cases as well. Let's look at them!
Before:
export const epic = (actions$: Observable<MyActions>) =>
actions$.pipe(
ofType(INCREMENT),
map(action => {
// action is correctly typed here
})
)
After
export const epic = (actions$: Observable<AnyAction>) =>
actions$.pipe(
filter(increment.match),
map(action => {
// action is correctly typed here
})
)
So we are just moving from the special case ofType
that tried to pull it's own "discriminating union" over the observable action type to the more general filter
method that just accepts any type guard function.
Redux saga already works out-of-the box with action creators that have a .type
property for effects like take
with another saga as the second argument. So using both redux toolkit action creators as well as the withMatcher
-created action creators from above will work just fine without any further modifications.
But, generally redux-saga
with TypeScript is a bit of a pain: the result of a yield
is just never defined, so you still need the types around for manual casting:
import { take } from 'redux-saga/effects'
function* exampleSaga() {
// cannot be inferred and needs to be manually typed
const action: IncrementActionType = yield take(slice.actions.incrementBy)
}
But... did you know that there is a library called typed-redux-saga
?
import { take } from 'typed-redux-saga'
function* exampleSaga() {
// correctly inferred as { payload: number; type: string; }
const action = yield* take(slice.actions.incrementBy)
}
It slightly changes the semantics of yielding effects: instead of yield
, you are now using yield*
. But apart from that, everything is the same. And it just works, with type inference at every corner!
Custom middleware works just like the reducer example above: switch ... case
becomes if ... else
with type guards. Nothing to worry about here.
Now, all that said, there is one last valid-ish use for an application-wide MyActions
type: Some people want to prevent wrongly typed actions to be passed into dispatch
. Yes, I get you.
But also: Are you serious? You are going around and hand-writing actions in the first place?
My solution: make it a rule in your team to always use action creators. Those will also be typed correctly and work as an equally good solution.
All without going through the work of manually gathering all your action types in one place.
By the way: If someone were to write an eslint rule for that, we'd probably be very happy to ship that with redux toolkit as a recommendation ;)