This blog post takes by granted that you are aware of useReducer logic and the basics regarding TypeScript.
Bringing TypeScript to the table
In the previous blog post we went in full detail on how to leverage React's useReducer, but there is still something missing for it to be fully bullet proof - TypeScript.
Why does it help
When applying TypeScript into useReducer you will not only feel a sense of security, but also, feel a lot more confident to touch code and modify any logic related with the states inside the reducer.
Pros of using TypeScript:
- Type safety
- Type completion
- Makes sure all states are handled
- Makes sure an Action sends the correct data
Cons of using TypeScript
- Brings a little more complexity
- Makes it harder to hack in a new state quickly
From where I see it, the pros overcome the cons by a lot and as such, I strongly advise you to add some sort of typing to your code.
Typing fetchReducer
In the last post, we finished with this plain JS reducer:
Typing Actions
To start, we need to type the different possible actions, so that we have type completion depending on what we are dispatching.
1- Define Action
type Action<DataT, ErrorT> ={}
Action object needs to take in two generics, one for the Data type and one of the Error type.
2- Define FETCH
{ type: "FETCH" }
For FETCH we really only need to define the type's property type, which is a string literal and nothing more.
3- Define RESOLVE
{ type: "RESOLVE", data: DataT }
When we dispatch RESOLVE it means that the fetch was successful and we already have the data - this action ensures that when we do dispatch({type: "RESOLVE"}) there is a type error for not passing the data.
4- Define REJECT
{ type: "REJECT", error: ErrorT }
REJECT acts pretty much as the success action, meaning, that when we dispatch this action, TypeScript will make us pass an error along.
5- Union of actions
type Action<DataT, ErrorT> =
| { type: "FETCH" }
| { type: "RESOLVE"; data: DataT }
| { type: "REJECT"; error: ErrorT };
Our action final type is just an union of all our defined actions, meaning, it can take any of those forms.
Typing States
In order to add more strictness to our reducer, each one of the states should have their own type definition.
All of these states must have the same properties, status, data and error, but for each one of the states, these properties will have their own type definitions, depending on the situation.
1- Typing iddle
type IddleState<DataT> = {
status: "idle";
data: Nullable<DataT>;
error: null;
};
The iddle state takes the DataT generic, so that it allows the reducer to start with initial data. Everything else is pretty standard for all the other reducer states.
2- Typing loading
type LoadingState<DataT, ErrorT> = {
status: "loading";
data: Nullable<DataT>;
error: Nullable<ErrorT>;
};
The loading state needs to take both DataT and ErrorT generics, as it depends too much on the implementation details if we wanna show or not errors while fetching new data.
3- Typing success
type SucessState<DataT> = {
status: "success";
data: DataT;
error: null;
};
The success state only needs the DataT generic and we can already define the error property can be nothing but null, this way, we protect our selves to set errors while in the success state (impossible state)!
4- Typing failure
type FailureState<ErrorT> = {
status: "failure";
data: null;
error: ErrorT;
};
The failure state behaves pretty much like the success one, but in the opposite direction, by setting the error needs a value and that the data must be of the null type.
5- Union of States
type State<DataT, ErrorT> =
| IddleState<DataT>
| LoadingState<DataT, ErrorT>
| SucessState<DataT>
| FailureState<ErrorT>;
Just like our Action type, State is also just an union of all the possible states that our reducer can return
Typing reducer function
Now that we have all our states and actions properly typed, it's just a matter of adding those to fetchReducer function it self.
1- Adding generics to the function
function fetchReducer<DataT, ErrorT = string>(
currentState,
action
){
...
}
We defined ErrorT as an optional generic by defining it as string by default.
2-Typing the arguments and the return type
function fetchReducer<DataT, ErrorT = string>(
currentState: State<DataT, ErrorT>,
action: Action<DataT, ErrorT>
): State<DataT, ErrorT> {
...
}
We just need to take our existing Action and State defined types, and add them to the respective parameters.
For the return type, it was also just a matter of defining that this reducer, can only return any of the states that is inside the State union type.
Typing useFetchReducer
Although the reducer function is already properly typed, we still need to add typing to our custom useReducer hook.
1- Passing the generics to the useFetchReducer
// added the generics here
function useFetchReducer<DataT, ErrorT = string>(
initialData
){
// removed them from the reducer
function fetchReducer(
state: State<DataT, ErrorT>,
event: Event<DataT, ErrorT>
)
}
By providing generics to the useFetchReducer hook, we don't need to have them on the reducer's signature anymore, as we can use the ones provided above and keep things consistent.
2-Typing initialData argument
function useFetchReducer<DataT, ErrorT = string>(
initialData: Nullable<DataT> = null
): [State<DataT, ErrorT>, React.Dispatch<Action<DataT, ErrorT>>] {...}
As far as initalData goes, if you wanted to pass in anything, it would have to be the same type that you defined your generic previously.
3-Typing initialState constant
const initialState: IddleState<DataT> = {
status: "idle",
data: initialData,
error: null,
};
We should use the IddleState type for the initialState constant, this way, if we decide to change it, TypeScript will make sure they are in sync.
The final type
import { useReducer } from "react";
type Nullable<T> = T | null | undefined;
type IddleState<DataT> = {
status: "idle";
data: Nullable<DataT>;
error: null;
};
type LoadingState<DataT, ErrorT> = {
status: "loading";
data: Nullable<DataT>;
error: Nullable<ErrorT>;
};
type SucessState<DataT> = {
status: "success";
data: DataT;
error: null;
};
type FailureState<ErrorT> = {
status: "failure";
data: null;
error: ErrorT;
};
type State<DataT, ErrorT> =
| IddleState<DataT>
| LoadingState<DataT, ErrorT>
| SucessState<DataT>
| FailureState<ErrorT>;
type Event<DataT, ErrorT> =
| { type: "FETCH" }
| { type: "RESOLVE"; data: DataT }
| { type: "REJECT"; error: ErrorT };
function useFetchReducer<DataT, ErrorT = string>(
initialData: Nullable<DataT> = null
) {
const initialState: IddleState<DataT> = {
status: "idle",
data: initialData,
error: null,
};
function fetchReducer(
state: State<DataT, ErrorT>,
event: Event<DataT, ErrorT>
): State<DataT, ErrorT> {
switch (event.type) {
case "FETCH":
return {
...state,
status: "loading",
};
case "RESOLVE":
return {
status: "success",
data: event.data,
error: null
};
case "REJECT":
return {
status: "failure",
data: null,
error: event.error,
};
default:
return state;
}
}
return useReducer(fetchReducer, initialState);
}
After all this typing, we should be pretty safe when trying to access any reducer's state or even when dispatching actions.
Dispatching Actions
As you can perceive from this GIF, TypeScript doesn't allow us to pass in incorrect Actions into the dispatcher function
Accessing reducer's state
If you look closely, you will notice that TypeScript can infer what's the data and error types by the current state.
This feature it's called Discriminating Unions and it works by having a Discriminator property in each one of the union types, that can help TypeScript narrow down which is the current state - in our case it is the status, which is unique for each of union types.
Conclusion
By using TypeScript in conjunction with the useReducer hook, you will be able to create robust React UI's, as well as iterate on top of them with much more confidence.
Summarizing everything we discussed above, these are the steps you should take to create a properly typed useReducer hook:
1- Type each action individually and create a super type, which is the union of all of them;
2 - Type each state individually and create a super type, which is the union of all of them;
3 - Add the necessary generic types to the useReducer and reducer function.
And that's it, you just improved your Developer Experience by a lot, and not only that, but by doing all these typing, you ended up creating a thin testing layer that will probably spare you from many coming bugs.
Make sure to follow me on twitter if you want read about TypeScript best practices or just web development in general!
Top comments (1)
Thank you for making this tutorial, but you still need Part 3 for useContext