Reducing Typescript and Redux Boilerplate with Partial Actions
Static types can help reduce defects in evolving codebases, but their benefits need to balance out against the inevitable boilerplate. We’ve previously used TypeScript to secure the Redux dispatch flow, but the repetition involved didn’t feel good at the time and hasn’t gotten any better with age.
The problem is that we want to use type-narrowing to reveal logical issues, while still being able to describe like actions in generic terms. Consider a family of actions representing the states of an API request:
// actions.ts
type ListRequest = {
count?: number
page?: number
}
type Books = {
resource: string,
items: Array<Book>
}
export type Action =
{ type: 'LIST_BOOKS_REQUEST', request: ListRequest }
| { type: 'LIST_BOOKS_RESPONSE', request: ListRequest, response: Books }
| { type: 'LIST_BOOKS_ERROR', request: ListRequest, error: string }
We should be able to count on strong, static guarantees anywhere we dispatch or
consume the LIST_BOOKS actions.
// reducers/books.ts
import { Action } from '../actions'
type Books = {
isLoading: boolean,
error: null | string,
books: Array<Book>,
}
const initialState = {
books: [],
isLoading: false,
error: null,
}
function books (state: Books = initialState, action: Action): Books {
switch (action.type) {
case 'LIST_BOOKS_REQUEST':
return { ...state, isLoading: true }
case 'LIST_BOOKS_ERROR':
return { ...state, isLoading: false, error: action.error }
case 'LIST_BOOKS_RESPONSE':
return {
error: null,
isLoading: false,
books: state.books.concat(action.response.items)
}
default:
return state
}
}
We would see a compiler error if books tried to access an unknown field.
Good. But in order to create actions from the LIST_BOOKS family, we need to
explicitly set both their types and their contents. In the previous attempt, we
needed a fairly hefty definition to be able to represent asynchronous
actions in a reasonably generic way:
const _listBooks: ApiAction<ListRequest, Books> = {
request: (request) =>
({ type: 'LIST_BOOKS_REQUEST', request }),
success: (response, request) =>
({ type: 'LIST_BOOKS_RESPONSE', request, response }),
error: (error, request) =>
({ type: 'LIST_BOOKS_ERROR', request, error }),
}
function createApiAction<Q, S>(a: ApiAction<Q, S>, fetch: (q: Q) => Promise<S>) {
return (req?: Q) => {
// Make API request and handle result, dispatching
// appropriate actions along the way
}
}
export const listBooks = createApiAction(_listBooks, opts => api.books.list(opts))
The ApiAction type enables a generic interface, but the type conversion
underpinning it in _listBooks is a compromise. Since we can’t define type
strings dynamically, every new API action family we define will need its own
implementation. The common interface is better than working with bespoke
actions. But it’s hardly a joy.
Partial Actions
The React ecosystem has trained us (quite rightly) to prize obviousness. Using discrete actions to represent changes within the application makes it clear–sometimes painfully clear–to follow what’s going on. We’re about to break all that.
The little bargain we’re about to strike will but save us a heap of boilerplate, but at the cost of discreet actions. We’ll lose a degree of obviousness in reducer logic and middleware. We’ll keep type-safety. Goethe can opine as he will.
Ready?
Returning to our first example, let’s replace the three actions in the
LIST_BOOKS family with a single type full of optional properties:
export type Action = {
type: 'LIST_BOOKS',
request?: ListRequest,
response?: Books,
error?: string,
}
We can think of this as a “partial” action. Like other forms of deferred state,
the LIST_BOOKS action will be filled out with additional content as the
request proceeds.
Remember that uncomfortable thing we were about to do? This is it. But using this pattern, we can now extract a generic type for the possible values of an API (or really any asynchronous) request:
type ApiAction<Q, S> = {
request?: Q,
response?: S,
error?: string,
}
export type Action =
({ type: 'LIST_BOOKS' } & APIAction<ListRequest, Books>)
References to LIST_BOOKS elsewhere will still be narrowed to the correct
type, but we can no longer refer to _ERROR and _SUCCESS actions
representing the possible outcomes. Instead, we’ll need to derive state from
the action’s content.
function books (prevState: Books = initialState, action: Action): Books {
if (action.type === 'LIST_BOOKS') {
const state = Object.assign({}, initialState)
if (action.response) {
state.books = state.books.concat(action.response.items)
} else if (action.error) {
state.error = action.error
} else {
state.isLoading = true
}
return state
}
return prevState
}
Conclusion
The upside? Reusing the type string across multiple states can save quite a bit of ceremony–in this example replacing the actions in a traditional TypeScript/redux implementation, boilerplate dropped by over 50%.
But whether it’s worth breaking the boundary between actions’ responsibilities will depend on the project and team. Partial actions are just a compromise between language and convention that may make sense in one context but not in another.
And as ever, let me know how it goes!