DEV Community: Pierre Ouannes

React & TypeScript: how to type hooks (a complete guide)

Pierre Ouannes — Tue, 12 Oct 2021 19:29:39 +0000

Using hooks is one of the most common things you do when writing React applications. If you use TypeScript in your apps, knowing how to type hooks properly is very important (and if you don't use TypeScript, you should seriously think about it!).

In this article we'll go over how to type each usual hook React provides us. There are also a few bonuses sprinkled in there, like how to type forwardRef and how to type custom hooks.

This post is meant both as a tutorial that you can read linearly, but also as a reference that you can go back to whenever you have doubts about any of the topics covered. Feel free to bookmark this page for easy access later on.

Note: typing hooks in React relies heavily on the concept of "generics" in TypeScript. If you're not familiar with that topic, check out this article going over what generic types are in TypeScript, and their application to React before you continue with this article.

Rely on type inference if you can

Before diving into the meat of the subject, we have to talk a bit about type inference.

In a lot of cases, TypeScript can infer the type of your hooks itself without your help. In those cases, you don't need to do anything yourself.

For example, the following is perfectly valid TypeScript, and works as you would want:

const [greeting, setGreeting] = useState('Hello World');

TypeScript will understand that greeting is supposed to be a string, and will also assign the right type to setGreeting as a result.

When to not rely on type inference

Type inference fails in two main cases.

The inferred type is too permissive for your use case.
The inferred type is wrong.

Let's explain both of these with examples.

Inferred type is too permissive

Let's look back at our previous example - we had a greeting of type string. But let's say the greeting could only have one of three predetermined values.

In that case, we would want greeting to have a very specific type, for example this one:

type Greeting = 'Hello World' | 'Hey!' | "What's up?";

Note: this type uses both a union type and literal types.

In that case, the inferred type is too permissive (string, instead of the specific subset of 3 strings we want), and you have to specify the type yourself:

const [greeting, setGreeting] = useState<Greeting>('Hello World');

The inferred type is wrong

Sometimes, the inferred type is wrong (or at least too restrictive/not the one you want). This happens frequently in React with default values in useState. Let's say that the initial value of greeting is null:

const [greeting, setGreeting] = useState(null);

In this case, TypeScript will infer that greeting is of type null (which means that it's always null). That's obviously wrong: we will want to set greeting to a string later on.

So you have to tell TypeScript that it can be something else:

const [greeting, setGreeting] = useState<string | null>(null);

With this, TypeScript will properly understand that greeting can be either null or a string.

Now that we are clear on when we can and can't rely on inferred types, let's see how to type each hook! I've already spoiled the first one a bit...

How to type `useState`

This will be short, as it's pretty simple and I've already shown multiple examples in the previous section.

const [greeting, setGreeting] = useState<string | null>(null);

That's it: you just have to specify the type of the state in the generic.

How to type `useReducer`

useReducer is a bit more complex to type than useState, because it has more moving parts.

There are two things to type: the state and the action.

If you're not comfortable with useReducer and the associated concepts, I would suggest giving How to use React useReducer like a pro a read.

Here is a useReducer example from my article on it. We will learn how to add proper types to it:

import { useReducer } from 'react';

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'username':
      return { ...state, username: action.payload };
    case 'email':
      return { ...state, email: action.payload };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);
  return (
    <div>
      <input
        type="text"
        value={state.username}
        onChange={(event) =>
          dispatch({ type: 'username', payload: event.target.value })
        }
      />
      <input
        type="email"
        value={state.email}
        onChange={(event) =>
          dispatch({ type: 'email', payload: event.target.value })
        }
      />
    </div>
  );
};

export default Form;

Let's start with typing the state.

How to type the reducer state

We have two choices to type the state:

Use the initialValue (if we have it) with the typeof operator
Define a type alias State, and use that

Here's the typeof initialValue option:

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state: typeof initialValue, action) => {
  switch (action.type) {
    case 'username':
      return {...state,  username: action.payload };
    case 'email':
      return {...state,  email: action.payload };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

And here's the type alias option:

type State = {
  username: string;
  email: string;
};

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state: State, action) => {
  switch (action.type) {
    case 'username':
      return { ...state, username: action.payload };
    case 'email':
      return { ...state, email: action.payload };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

How to type the reducer action

The reducer action is a tad harder to type than the state because its structure changes depending on the exact action.

For example for the 'username' action we might expect the following type:

type UsernameAction = {
  type: 'username';
  payload: string;
};

But for the 'reset' action we don't need a payload:

type ResetAction = {
  type: 'reset';
};

So how do we tell TypeScript that the action object can have very different structures depending on its exact type? With the help of discrimated unions!

And they even have a very nice syntax (in my opinion):

const initialValue = {
  username: "",
  email: ""
};

type Action =
  | { type: "username"; payload: string }
  | { type: "email"; payload: string }
  | { type: "reset" };

const reducer = (state: typeof initialValue, action: Action) => {
  switch (action.type) {
    case "username":
      return {...state, username: action.payload };
    case "email":
      return { ...state, email: action.payload };
    case "reset":
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

The Action type is saying that it can take any of the three types contained in the discriminated union. So if TypeScript sees that action.type is the string "username", it will automatically know that it should be in the first case and that the payload should be a string. Handy, isn't it?

And that's it! You have your useReducer fully typed, as it's able to infer everything it needs from the types of the reducer function.

Here is the example in its entirety:

import { useReducer } from 'react';

const initialValue = {
  username: '',
  email: '',
};

type Action =
  | { type: 'username'; payload: string }
  | { type: 'email'; payload: string }
  | { type: 'reset' };

const reducer = (state: typeof initialValue, action: Action) => {
  switch (action.type) {
    case 'username':
      return { ...state, username: action.payload };
    case 'email':
      return { ...state, email: action.payload };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);

  return (
    <div>
      <input
        type="text"
        value={state.username}
        onChange={(event) =>
          dispatch({ type: 'username', payload: event.target.value })
        }
      />
      <input
        type="email"
        value={state.email}
        onChange={(event) =>
          dispatch({ type: 'email', payload: event.target.value })
        }
      />
    </div>
  );
};

export default Form;

How to type `useRef`

useRef has two main uses:

To hold a custom mutable value, a bit like useState (but with important differences)
To keep a reference to a DOM object

Both of those uses require different types. Let's begin with the simpler one (at least type-wise).

How to type `useRef` for mutable values

It's basically the same as useState. You want useRef to hold a custom value, so you tell it the type.

Let's take this example directly from the React documentation:

function Timer() {
  const intervalRef = useRef<number | undefined>();

  useEffect(() => {
    const id = setInterval(() => {
      // ...
    });
    intervalRef.current = id;
    return () => {
      clearInterval(intervalRef.current);
    };
  });

  // ...
}

If you want a reminder on how the setInterval function works (in general but also in React), I've got you covered.

How to type `useRef` for DOM nodes

A classic use case for using useRef with DOM nodes is focusing input elements:

import { useRef, useEffect } from 'react';

const AutoFocusInput = () => {
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  return <input ref={inputRef} type="text" value="Hello World" />;
};

export default AutoFocusInput;

TypeScript has built-in DOM element types that we can make use of. The structure of those types is always the same: if name is the name of the HTML tag you're using, the corresponding type will be HTMLNameElement.

Note: knowing HTML element type names is usually straightforward, but I've always struggled to remember the name of the a tag type for some reason. It's HTMLAnchorElement. Another one that isn't obvious is the one for <h1> tags (and all the others). It's HTMLHeadingElement.

For our input, the name of the type will thus be HTMLInputElement:

import { useRef, useEffect } from 'react';

const AutoFocusInput = () => {
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    inputRef.current?.focus();
  }, []);

  return <input ref={inputRef} type="text" value="Hello World" />;
};

export default AutoFocusInput;

Note that we've added a question mark to inputRef.current?.focus(). This is because for TypeScript, inputRef.current is possibly null. In this case, we know that it won't be null because it's populated by React before useEffect first runs. Adding the question mark is the simplest way to make TypeScript happy about that issue.

I find it pretty fun to go look at the type definitions as they are defined in the TypeScript source code. Here is the link for HTMLInputElement!

Bonus: how to type `forwardRef`

Sometimes you want to forward refs to children components. To do that in React we have to wrap the component with forwardRef.

Here's the link to the React documentation on forwardRef if you want more info.

We'll see a simple example using a controlled Input component (that doesn't do much but hey, it's just an example):

import { ChangeEvent } from 'react';

type Props = {
  value: string,
  handleChange: (event: ChangeEvent<HTMLInputElement>) => void,
};

const TextInput = ({ value, handleChange }: Props) => {
  return <input type="text" value={value} onChange={handleChange} />;
};

You can learn all about using events with TypeScript and React in this article!

Now here it is with forwardRef:

import { fowardRef, ChangeEvent } from 'react';

type Props = {
  value: string;
  handleChange: (event: ChangeEvent<HTMLInputElement>) => void;
};

const TextInput = forwardRef<HTMLInputElement, Props>(
  ({ value, handleChange }, ref) => {
    return (
      <input ref={ref} type="text" value={value} onChange={handleChange} />
    );
  }
);

The syntax isn't very pretty in my opinion, but overall it's very similar to typing useRef. You just have to provide forwardRef with what HTMLElement it should expect (in that case, HTMLInputElement).

The one thing which is a bit weird and that can be tricky is that the order of the component arguments ref and props is not the same as in the generic <HTMLInputElement, Props>.

It's an easy mistake to make, but TypeScript will yell at you if you do it so you should notice it quickly enough. 😁

How to type `useEffect` and `useLayoutEffect`

Those are pretty easy since you don't have to give them any type.

The only thing to be aware of is implicit returns. What I mean by that is that the callback inside useEffect is expected to either return nothing or a Destructor function that will clean up any side effect (and Destructor is the actual name of the type! See for yourself).

Sometimes you might implicitly return things, which won't make TypeScript happy (so you should avoid it). This is an example of such a case:

const doSomething = () => {
  return 'hey there';
};

useEffect(() => doSomething(), []);

In the code above, doSomething returns a string, which means that the return type of the callback inside useEffect is also a string. TypeScript doesn't want that, so it's not happy.

How to type `useMemo` and `useCallback`

Those are even easier than useEffect and useLayoutEffect since you don't need to type anything. Everything is inferred for you.

How to type React contexts

Note: I wrote a guide on using context in React. Check it out if you have questions about using contexts in React! It's not an intro to contexts though, so if you're a beginner you should rather check the React documentation article on contexts.

This is the example we'll be using:

import { createContext, useState } from 'react';

const AuthContext = createContext(undefined);

const AuthContextProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  const signOut = () => {
    setUser(null);
  };

  useEffect(() => {
    // fetch user and setUser
  }, []);

  return (
    <AuthContext.Provider value={{ user, signOut }}>
      {children}
    </AuthContext.Provider>
  );
};

export default AuthContextProvider;

It's a basic form of the context you might have in your app to manage the authentification state of users.

Providing types to the context is pretty easy. First, create a type for the value of the context, then provide it to the createContext function as a generic type:

import React, { createContext, useEffect, useState, ReactNode } from 'react';

type User = {
  name: string;
  email: string;
  freeTrial: boolean;
};

type AuthValue = {
  user: User | null;
  signOut: () => void;
};

const AuthContext = createContext<AuthValue | undefined>(undefined);

type Props = {
  children: ReactNode;
};

const AuthContextProvider = ({ children }: Props) => {
  const [user, setUser] = useState(null);

  const signOut = () => {
    setUser(null);
  };

  useEffect(() => {
    // fetch user and setUser
  }, []);

  return (
    <AuthContext.Provider value={{ user, signOut }}>
      {children}
    </AuthContext.Provider>
  );
};

export default AuthContextProvider;

Once you have provided the type to createContext, everything else will be populated for you thanks to the magic of generics.

One issue with the implementation above is that as far as TypeScript is concerned, the context value can be undefined. We know that it won't be because we are populating it directly in the AuthContextProvider. So how can we tell TypeScript that?

There are several solutions to that, but the one I prefer is using a custom context getter hook. This is something you should be probably doing anyway, regardless of TypeScript:

export const useAuthContext = () => {
  const context = useContext(AuthContext);

  if (context === undefined) {
    throw new Error('useAuthContext must be used inside AuthContext');
  }

  return context;
};

The condition in this hook acts as a type guard and guarantees that the returned context won't be undefined.

Bonus: how to type custom hooks

Typing custom hooks is basically the same as typing normal functions, there's nothing to be aware of in particular.

It's relatively common to be using generic types when using custom hooks, so be sure to check out my article about generics if you want to learn more about them and their usage in React.

Wrap up

That's it folks!

I hope this article helped you (and will help you in the future) to know how to type hooks in React.

React & TypeScript: use generics to improve your types

Pierre Ouannes — Tue, 05 Oct 2021 18:32:40 +0000

While TypeScript is a godsend for React developers, its syntax is fairly intimidating to newcomers. I think generics are a big part of that: they look weird, their purpose isn't obvious, and they can be quite hard to parse.

This article aims to help you understand and demystify TypeScript generics in general, and their application to React in particular. They aren't that complex: if you understand functions, then generics aren't that far off.

What are generics in TypeScript?

To understand generics, we'll first start by comparing a standard TypeScript type to a JavaScript object.

// a JavaScript object
const user = {
  name: 'John',
  status: 'online',
};

// and its TypeScript type
type User = {
  name: string;
  status: string;
};

As you can see, very close. The main difference is that in JavaScript you care about the values of your variables, while in TypeScript you care about the type of your variables.

One thing we can say about our User type is that its status property is too vague. A status usually has predefined values, let's say in this instance it could be either "online" or "offline". We can modify our type:

type User = {
  name: string;
  status: 'online' | 'offline';
};

But that assumes we already know the kind of statuses there are. What if we don't, and the actual list of statuses changes? That's where generics come in: they let you specify a type that can change depending on the usage.

We'll see how to implement this new type afterward, but for our User example using a generic type would look like this:

// `User` is now a generic type
const user: User<'online' | 'offline'>;

// we can easily add a new status "idle" if we want
const user: User<'online' | 'offline' | 'idle'>;

What the above is saying is "the user variable is an object of type User, and by the way the status options for this user are either 'online' or 'offline'" (and in the second example you add "idle" to that list).

All right, the syntax with angle brackets < > looks a bit weird. I agree. But you get used to it.

Pretty cool right? Now here is how to implement this type:

// generic type definition
type User<StatusOptions> = {
  name: string;
  status: StatusOptions;
};

StatusOptions is called a "type variable" and User is said to be a "generic type".

Again, it might look weird to you. But this is really just a function! If I were to write it using a JavaScript-like syntax (not valid TypeScript), it would look something like this:

type User = (StatusOption) => {
  return {
    name: string;
    status: StatusOptions;
  }
}

As you can see, it's really just the TypeScript equivalent of functions. And you can do cool stuff with it.

For example imagine our User accepted an array of statuses instead of a single status like before. This is still very easy to do with a generic type:

// defining the type
type User<StatusOptions> = {
  name: string;
  status: StatusOptions[];
};

// the type usage is still the same
const user: User<'online' | 'offline'>;

If you want to learn more about generics, you can check out TypeScript's guide on them.

Why generics can be very useful

Now that you know what generic types are and how they work, you might be asking yourself why we need this. Our example above is pretty contrived after all: you could define a type Status and use that instead:

type Status = 'online' | 'offline';

type User = {
  name: string;
  status: Status;
};

That's true in this (fairly simple) example, but there are a lot of situations where you can't do that. It's usually the case when you want to have a shared type used in multiple instances that each has some difference: you want the type to be dynamic and adapt to how it's used.

A very common example is having a function that returns the same type as its argument. The simplest form of this is the identity function, which returns whatever it's given:

function identity(arg) {
  return arg;
}

Pretty simple right? But how would you type this, if the arg argument can be any type? And don't say using any!

That's right, generics:

function identity<ArgType>(arg: ArgType): ArgType {
  return arg;
}

Once again, I find this syntax a bit complex to parse, but all it's really saying is: "the identity function can take any type (ArgType), and that type will be both the type of its argument and its return type".

And this is how you would use that function and specify its type:

const greeting = identity<string>('Hello World!');

In this specific instance <string> isn't necessary since TypeScript can infer the type itself, but sometimes it can't (or does it wrongly) and you have to specify the type yourself.

Multiple type variables

You're not limited to one type variable, you can use as many as you want. For example:

function identities<ArgType1, ArgType2>(
  arg1: ArgType1,
  arg2: ArgType2
): [ArgType1, ArgType2] {
  return [arg1, arg2];
}

In this instance, identities takes 2 arguments and returns them in an array.

Generics syntax for arrow functions in JSX

You might have noticed that I've only used the regular function syntax for now, not the arrow function syntax introduced in ES6.

// an arrow function
const identity = (arg) => {
  return arg;
};

The reason is that TypeScript doesn't handle arrow functions quite as well as regular functions (when using JSX). You might think that you can do this:

// this doesn't work
const identity<ArgType> = (arg: ArgType): ArgType => {
  return arg;
}

// this doesn't work either
const identity = <ArgType>(arg: ArgType): ArgType => {
  return arg;
}

But this doesn't work in TypeScript. Instead, you have to do one of the following:

// use this
const identity = <ArgType,>(arg: ArgType): ArgType => {
  return arg;
}

// or this
const identity = <ArgType extends unknown>(arg: ArgType): ArgType => {
  return arg;
}

I would advise using the first option because it's cleaner, but the comma still looks a bit weird to me.

To be clear, this issue stems for the fact that we're using TypeScript with JSX (which is called TSX). In normal TypeScript, you wouldn't have to use this workaround.

A word of warning on type variable names

For some reason, it's conventional in the TypeScript world to give one letter names to the type variable in generic types.

// instead of this
function identity<ArgType>(arg: ArgType): ArgType {
  return arg;
}

// you would usually see this
function identity<T>(arg: T): T {
  return arg;
}

Using full words for the type variable name can indeed make the code quite verbose, but I still think that it's way easier to understand than when using the single-letter option.

I encourage you to use actual words in your generic names like you would do elsewhere in your code. But be aware that you will very often see the single-letter variant in the wild.

Bonus: a generic type example from open source: `useState` itself!

To wrap up this section on generic types, I thought it could be fun to have a look at a generic type in the wild. And what better example than the React library itself?

Fair warning: this section is a bit more complex than the others in this article. Feel free to revisit it later if you don't get it at first.

Let's have a look at the type definition for our beloved hook useState:

function useState<S>(
  initialState: S | (() => S)
): [S, Dispatch<SetStateAction<S>>];

You can't say I didn't warn you - type definitions with generics aren't very pretty. Or maybe that's just me!

Anyway, let's understand this type definition step by step:

We begin by defining a function, useState, which takes a generic type called S.
That function accepts one and only one argument: an initialState.
- That initial state can either be a variable of type S (our generic type), or a function whose return type is S.
useState then returns an array with two elements:
- The first is of type S (it's our state value).
- The second is of the Dispatch type, to which the generic type SetStateAction<S> is applied. SetStateAction<S> itself is the SetStateAction type with the generic type S applied (it's our state setter).

This last part is a bit complicated, so let's look into it a bit further.

First up, let's look up SetStateAction:

type SetStateAction<S> = S | ((prevState: S) => S);

All right so SetStateAction is also a generic type that can either be a variable of type S, or a function that has S as both its argument type and its return type.

This reminds me of what we provide to setState, right? You can either directly provide the new state value, or provide a function that builds the new state value off the old one.

Now what's Dispatch?

type Dispatch<A> = (value: A) => void;

All right so this simply has an argument of type whatever the generic type is, and returns nothing.

Putting it all together:

// this type:
type Dispatch<SetStateAction<S>>

// can be refactored into this type:
type (value: S | ((prevState: S) => S)) => void

So it's a function that accepts either a value S or a function S => S, and returns nothing.

That indeed matches our usage of setState.

And that's the whole type definition of useState! Now in reality the type is overloaded (meaning other type definitions might apply, depending on context), but this is the main one. The other definition just deals with the case where you give no argument to useState, so initialState is undefined.

Here it is for reference:

function useState<S = undefined>(): [
  S | undefined,
  Dispatch<SetStateAction<S | undefined>>
];

Using generics in React

Now that we've understood the general TypeScript concept of generic types, we can see how to apply it in React code.

Generic types for React hooks like `useState`

Hooks are just normal JavaScript functions that React treats a bit differently. It follows that using a generic type with a hook is the same as using it with a normal JavaScript function:

// normal JavaScript function
const greeting = identity<string>('Hello World');

// useState
const [greeting, setGreeting] = useState<string>('Hello World');

In the examples above you could omit the explicit generic type as TypeScript can infer it from the argument value. But sometimes TypeScript can't do that (or does it wrongly), and this is the syntax to use.

We'll see a live example of that in the next section.

If you want to learn how to type all hooks in React, stay tuned! An article on that subject will be out next week. Subscribe to be sure to see it!

Generic types for Component props

Let's say you're building a Select component for a form. Something like this:

import { useState, ChangeEvent } from 'react';

function Select({ options }) {
  const [value, setValue] = useState(options[0]?.value);

  function handleChange(event: ChangeEvent<HTMLSelectElement>) {
    setValue(event.target.value);
  }

  return (
    <select value={value} onChange={handleChange}>
      {options.map((option) => (
        <option key={option.value} value={option.value}>
          {option.label}
        </option>
      ))}
    </select>
  );
}

export default Select;

// `Select` usage
const mockOptions = [
  { value: 'banana', label: 'Banana 🍌' },
  { value: 'apple', label: 'Apple 🍎' },
  { value: 'coconut', label: 'Coconut 🥥' },
  { value: 'watermelon', label: 'Watermelon 🍉' },
];

function Form() {
  return <Select options={mockOptions} />;
}

If you're unsure about what's going on with the type of the event object in handleChange, I have an article explaining how to use TypeScript with events in React

Let's say that for the value of the options we can accept either a string or a number, but not both at the same time. How would you enforce that in the Select component?

The following doesn't work the way we want, do you know why?

type Option = {
  value: number | string;
  label: string;
};

type SelectProps = {
  options: Option[];
};

function Select({ options }: SelectProps) {
  const [value, setValue] = useState(options[0]?.value);

  function handleChange(event: ChangeEvent<HTMLSelectElement>) {
    setValue(event.target.value);
  }

  return (
    <select value={value} onChange={handleChange}>
      {options.map((option) => (
        <option key={option.value} value={option.value}>
          {option.label}
        </option>
      ))}
    </select>
  );
}

The reason it doesn't work is that in one options array you could have an option with a value of type number, and another option with a value of type string. We don't want that, but TypeScript would accept it.

// this would work with the previous `Select`
const mockOptions = [
  { value: 123, label: 'Banana 🍌' },
  { value: 'apple', label: 'Apple 🍎' },
  { value: 'coconut', label: 'Coconut 🥥' },
  { value: 'watermelon', label: 'Watermelon 🍉' },
];

The way to enforce the fact that we want either a number or an integer is by using generics:

type OptionValue = number | string;

type Option<Type extends OptionValue> = {
  value: Type;
  label: string;
};

type SelectProps<Type extends OptionValue> = {
  options: Option<Type>[];
};

function Select<Type extends OptionValue>({ options }: SelectProps<Type>) {
  const [value, setValue] = useState<Type>(options[0]?.value);

  function handleChange(event: ChangeEvent<HTMLSelectElement>) {
    setValue(event.target.value);
  }

  return (
    <select value={value} onChange={handleChange}>
      {options.map((option) => (
        <option key={option.value} value={option.value}>
          {option.label}
        </option>
      ))}
    </select>
  );
}

Take a minute to understand the code above. If you're not familiar with generic types, it probably looks quite weird.

One thing you might be asking is why we had to define OptionValue and then put extends OptionValue in a bunch of places.

Well imagine we don't do that, and instead of Type extends OptionValue we just put Type instead. How would the Select component know that the type Type can either be a number or a string but nothing else?

It can't. That's why we have to say: "Hey, this Type thing can either be a string or a number".

It's a detail unrelated to generics, but if you use the above code in an actual editor you'll probably get a TypeScript error inside the handleChange function.

The reason for that is that event.target.value will be converted to a string, even if it was a number. And useState expects the type Type, which can be a number. So there's an issue there.

The best way I've found to handle this is by using the index of the selected element instead, like so:

function handleChange(event: ChangeEvent<HTMLSelectElement>) {
  setValue(options[event.target.selectedIndex].value);
}

Wrap up

I hope this article helped you to better understand how generic types work. When you get to know them, they aren't so scary anymore 😊

Yes, the syntax can get some getting used to, and isn't very pretty. But generics are an important part of your TypeScript toolbox to create great TypeScript React applications, so don't shun them just for that.

Have fun building apps!

PS: Are there other generic type applications in React that I should mention in this article? If so, feel free to ping me on Twitter or shoot me an email at pierre@devtrium.com.

How to use React useReducer hook like a pro

Pierre Ouannes — Mon, 20 Sep 2021 19:15:03 +0000

Managing state in React is one of the main issues you'll be facing while developing React websites. useState is of course the most common way to create and manage state in (functional) React components. But do you know that useReducer can be a very powerful alternative?

There's also a lot of libraries offering opinionated ways to manage your entire (or part of) state, like Redux, Mobx, Recoil or XState.

But before jumping to a library to help you manage your state issues, you should be aware of another native way to manage your state in React: useReducer. It can be very powerful when used in the right way and for the right purpose. In fact, it's so powerful that the famous Redux library can be thought of as just a big, optimized useReducer (as we'll see).

In this article, we'll start by explaining what useReducer is and how to use it, giving you a good mental model and examples. We'll then go over a useState vs useReducer comparison to learn when to use which.

And for the TypeScript users out there, we'll also see how to use TypeScript and useReducer together.

Let's dive in!

What is React `useReducer` hook and how to use it

As mentioned in the introduction, useState and useReducer are the two native ways of managing state in React. You are probably already quite familiar with the former, so it's helpful to start there to understand useReducer.

`useState` and `useReducer`: a quick comparison

They are very similar at first glance. Let's see them side by side:

const [state, setState] = useState(initialValue);

const [state, dispatch] = useReducer(reducer, initialValue);

As you can see, in both cases the hook returns an array with two elements. The first is the state, and the second is a function that lets you modify the state: setState for useState, and dispatch for useReducer. We'll learn about how dispatch works later on.

An initial state is provided both for useState and useReducer. The main difference in the hook arguments is the reducer provided to useReducer.

For now, I'll just say that this reducer is a function that will handle the logic of how the state should be updated. We'll also learn about it in detail later in the article.

Now let's see how to change the state using either setState or dispatch. For this, we'll use the tried and tested example of a counter - we want to increment it by one when a button is clicked:

// with `useState`
<button onClick={() => setCount(prevCount => prevCount + 1)}>
  +
</button>

// with `useReducer`
<button onClick={() => dispatch({type: 'increment', payload: 1})}>
  +
</button>

While the useState version is probably familiar to you (if not, it might be because we are using the functional update form of setState), the useReducer version might look a bit strange.

Why are we passing an object with type and payload properties? Where is the (magic?) value 'increment' coming from? Fret not, the mysteries will be explained!

For now, you can notice that both versions are still pretty similar. In either case, you update the state by calling the update function (setState or dispatch) with information on how exactly you want to update the state.

Let's now explore on a high level how the useReducer version exactly works.

`useReducer`: a backend mental model

In this section I want to give you a good mental model of how the useReducer hook works. This is important because when we're knee-deep in the implementation details, things can get a bit overwhelming. Especially if you've never worked with similar structures before.

One way to think about useReducer is to think of it as a backend. It might sound a bit strange, but bear with me: I'm very happy with this analogy and I think it explains reducers well.

A backend is usually structured with some way to persist data (a database) and an API that lets you modify the database.

That API has HTTP endpoints you can call. GET requests let you access the data, and POST requests let you modify it. When you do a POST request you can also give some parameters; for example if you want to create a new user you'll typically include the username, email and password of that new user in the HTTP POST request.

So, how is useReducer similar to a backend? Well:

state is the database. It stores your data.
dispatch is equivalent to the API endpoints being called to modify the database.
- You can choose which endpoint to call by specifying the type of the call.
- You can provide additional data with the payload property, which corresponds to the body of a POST request.
- Both type and payload are properties of an object which is given to the reducer. That object is called the action.
reducer is the logic of the API. It's called when the backend receives an API call (a dispatch call), and handles how to update the database based on the endpoint and request content (the action).

Here's a complete example of useReducer usage. Take a moment to take it in, and to compare it to the backend mental model described above.

import { useReducer } from 'react';

// initial state of the database
const initialState = { count: 0 };

// API logic: how to update the database when the
// 'increment' API endpoint is called
const reducer = (state, action) => {
  if (action.type === 'increment') {
    return { count: state.count + action.payload };
  }
};

function App() {
  // you can think of this as initializing and setting
  // up a connection to the backend
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      {/* Reading from the database */}
      Count: {state.count}
      {/* calling the API endpoint when the button is clicked */}
      <button onClick={() => dispatch({ type: 'increment', payload: 1 })}>
        +
      </button>
    </div>
  );
}

export default App;

Can you see how the two are related?

Remember that the code above shouldn't be used in production. It's a minimal version of the useReducer hook to help you compare it with the backend mental model, but it lacks several important things that you'll learn about in this article.

Now that (hopefully) you have a good idea of how useReducer is working on a high level, let's explore the details further.

How does the reducer work

We'll tackle the reducer first since it's where the main logic happens.

As you may have noticed from the example above, the reducer is a function that takes two arguments. The first is the current state, and the second is the action (which in our backend analogy corresponds to the API endpoint + any body the request might have).

Keep in mind that you'll never have to provide the arguments to the reducer yourself. This is handled by the useReducer hook automatically: the state is known, and the action is just the argument of dispatch which is passed along to the reducer as its second argument.

The state has whatever format you want (usually an object, but it can be anything really). The action can also be whatever you want, but there's some very commonly used convention on how to structure it and I advise you to follow those conventions- we'll be learning about them later. At least until you're familiar with them and confident that departing from those is really what you want.

So conventionally, the action is an object with one required property and one optional property:

type is the required property (analogous to the API endpoint). It tells the reducer what piece of logic it should be using to modify the state.
payload is the optional property (analogous to the body of the HTTP POST request, if any). It provides additional information to the reducer on how to modify the state.

In our previous example of a counter, state was an object with a single count property. action is an object whose type can be 'increment', and whose payload is the amount by which you want to increment the counter.

// this is an example `state`
const state = { count: 0 };

// this is an example `action`
const action = { type: 'increment', payload: 2 };

Reducers are usually structured with a switch statement on the action type, for example:

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.payload };
    case 'decrement':
      return { count: state.count - action.payload };
    case 'reset':
      return { count: 0 };
  }
};

In this example, the reducer accepts three kinds of action types: "increment", "decrement", and "reset". Both "increment" and "decrement" require an action payload that will determine the amount by which the counter is increased or decreased. On the contrary, the "reset" type doesn't require any payload, as it resets the counter back to 0.

This is a very simple example, and real-life reducers are usually much bigger and more complex. We'll see ways to improve how we write reducers in further sections, as well as examples of what a reducer would look like in a real-life app.

How does the dispatch function work?

If you have understood how the reducer works, understanding the dispatch function is pretty simple.

Whatever argument given dispatch when you call it will be the second argument given to your reducer function (the action). By convention, that argument is an object with a type and an optional payload, as we saw in the last section.

Using our last reducer example, if we wanted to make a button that decreases the counter by 2 on click it would look like this:

<button onClick={() => dispatch({ type: 'decrement', payload: 2 })}>
  -
</button>

And if we wanted to have a button that resets the counter to 0, still using our last example, you can omit the payload:

<button onClick={() => dispatch({ type: 'reset' })}>
  reset
</button>

One important thing to note on dispatch is that React guarantees that its identity won't change between renders. That means that you don't need to put it in dependency arrays (and if you do, it won't ever trigger the dependency array). This is the same behaviour as the setState function from useState.

If you're a bit fuzzy about that last paragraph, I've got you covered with this article on dependency arrays!

`useReducer` initial state

We haven't mentioned it a lot so far but useReducer also takes a second argument, which is the initial value you want to give to the state.

It's not a required parameter per se, but if you don't provide it the state will be undefined at first and that's rarely what you want.

You usually define the full structure of your reducer state in the initial state. It's commonly an object, and you shouldn't be adding new properties to that object inside your reducer.

In our counter example the initial state was simply:

// initial state of the database
const initialState = { count: 0 };

· · ·

// usage inside of the component
const [state, dispatch] = useReducer(reducer, initialState);

We'll see more examples of this further down the road.

`useReducer` tips and tricks

There are several ways in which we can improve our use of useReducer. Some of those are things you should really be doing, others are more matters of personal taste.

I've roughly classified them from important to optional, starting with the most important ones.

The reducer should throw an error for unknown action types

In our counter example we had a switch statement with three cases: "increment", "decrement" and "reset". If you did write this into your code editor, you might have noticed ESLint being mad at you.

You have ESLint right? If you don't you really should set it up!

ESLint (rightly) wants switch statements to have a default case. So, what should be the reducer default case when it's handling an unknown action type?

Some people like to simply return the state:

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.payload };
    case 'decrement':
      return { count: state.count - action.payload };
    case 'reset':
      return { count: 0 };
    default:
      return state;
  }
};

But I really don't like that. Either the action type is something you expect and should have a case for, or it's not, and returning the state is not what you want. This is basically creating a silent error when an incorrect action type is provided, and silent errors can be very hard to debug.

Instead, your default reducer case should be throwing an error:

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + action.payload };
    case 'decrement':
      return { count: state.count - action.payload };
    case 'reset':
      return { count: 0 };
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

That way, you won't miss a typo or forget about a case.

You should spread the state in every action

So far we have only seen a very simple useReducer example, in which the state is an object with only one property. Usually though, useReducer use cases call for state objects with at least a few properties.

A common useReducer usage is to handle forms. Here's an example with two input fields, but you could imagine the same with many more fields.

(Beware! The code below has a bug. Can you spot it?)

import { useReducer } from 'react';

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'username':
      return { username: action.payload };
    case 'email':
      return { email: action.payload };
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);
  return (
    <div>
      <input
        type="text"
        value={state.username}
        onChange={(event) =>
          dispatch({ type: 'username', payload: event.target.value })
        }
      />
      <input
        type="email"
        value={state.email}
        onChange={(event) =>
          dispatch({ type: 'email', payload: event.target.value })
        }
      />
    </div>
  );
};

export default Form;

The bug is in the reducer: updating username will completely override the previous state and delete email (and updating email will do the same to username).

The way to solve this issue is to remember to keep all the previous state every time you update a property. This can be achieved easily with the spread syntax:

import { useReducer } from 'react';

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'username':
      return { ...state, username: action.payload };
    case 'email':
      return { ...state, email: action.payload };
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);
  return (
    <div>
      <input
        value={state.username}
        onChange={(event) =>
          dispatch({ type: 'username', payload: event.target.value })
        }
      />
      <input
        value={state.email}
        onChange={(event) =>
          dispatch({ type: 'email', payload: event.target.value })
        }
      />
    </div>
  );
};

export default Form;

This example can actually be optimized further. You might have noticed that we are repeating ourselves a bit in the reducer: both the username and email cases have essentially the same logic. This isn't too bad for two fields but we could have many more.

There's a way to refactor the code to have only one action for all inputs, using the ES2015 feature of computed keys:

import { useReducer } from 'react';

const initialValue = {
  username: '',
  email: '',
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'textInput':
      return {
        ...state,
        [action.payload.key]: action.payload.value,
      };
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);
  return (
    <div>
      <input
        value={state.username}
        onChange={(event) =>
          dispatch({
            type: 'textInput',
            payload: { key: 'username', value: event.target.value },
          })
        }
      />
      <input
        value={state.email}
        onChange={(event) =>
          dispatch({
            type: 'textInput',
            payload: { key: 'email', value: event.target.value },
          })
        }
      />
    </div>
  );
};

export default Form;

As you can see, we're now left with only one action type: textInput. The action payload also has changed- it has become an object with a key (the property to update) and value (the value to update the key by).

Pretty neat if you ask me!

You might notice that we have one more place where we repeat ourselves in this code: the onChange event handler. The only thing that's changing is the payload.key.

And indeed, you could further extract that into a reusable action to which you only have to provide the key.

I tend to only have reusable actions when the reducer starts to get really big, or if very similar actions are repeated a lot.

This is a very common pattern though, and we'll show an example of it later on in the article.

Stick to the conventional action structure

What I mean by "conventional action structure" is the structure we've been using so far in this article: action should be an object literal with a required type and an optional payload.

This is the Redux way of structuring actions and is also the most commonly used. It's tried and tested, and a very good default for all of your useReducers.

The main con of that structure is that it can sometimes be a bit verbose. But unless you're very comfortable with useReducer I would advise you to stick to the Redux way.

Sugar syntax: deconstruct `type` and `payload` from action

This is a quality of life thing. Instead of repeating action.payload (and potentially action.type) everywhere in your reducer, you could directly deconstruct the reducer's second argument, like so:

const reducer = (state, { type, payload }) => {
  switch (type) {
    case 'increment':
      return { count: state.count + payload };
    case 'decrement':
      return { count: state.count - payload };
    case 'reset':
      return { count: 0 };
    default:
      throw new Error(`Unknown action type: ${type}`);
  }
};

You could even go a step further and also deconstruct the state. This is only handy if your reducer state is small enough, but it can be nice in those cases.

const reducer = ({ count }, { type, payload }) => {
  switch (type) {
    case 'increment':
      return { count: count + payload };
    case 'decrement':
      return { count: count - payload };
    case 'reset':
      return { count: 0 };
    default:
      throw new Error(`Unknown action type: ${type}`);
  }
};

That's it for the tips and tricks!

`useReducer` third parameter: lazy initialization

It's good to know that useReducer has an optional third argument. This argument is a function used to initialize the state lazily if you need to.

This is not used very often but it can be quite useful when you actually need it. The react documentation has a good example of how to use that lazy initializaiton.

`useState` vs `useReducer`: when to use which

Now that you know how useReducer works and how to use it in your components, we need to address an important question. Since useState and useReducer are two ways of managing state, which should you choose when?

These kinds of questions are always a tricky topic because the answer will usually change depending on who you ask, and it's also highly context-dependent. However, there are still guidelines that can orient you in your choice.

First off, know that useState should remain your default choice for managing React state. Only switch to useReducer if you start having trouble with useState (and if that trouble can be solved by switching to useReducer). At least until you're experienced enough with useReducer to know in advance which one to use.

I'll illustrate when to use useReducer over useState through a few examples.

Multiple pieces of state that rely on each other

One good use case for useReducer is when you have multiple pieces of state that rely on each other.

It's quite common when you're building forms. Let's say you have a text input and you want to track three things:

The value of the input.
Whether the input has already been "touched" by the user. This is useful to know whether to display an error. For example, if the field is required you want to display an error when it's empty. However, you don't want to display an error on the first render when the user has never visited the input before.
Whether there's an error.

With useState, you would have to use the hook three times and update three pieces of state separately each time there's a change.

With useReducer, the logic is actually quite simple:

import { useReducer } from 'react';

const initialValue = {
  value: '',
  touched: false,
  error: null,
};

const reducer = (state, { type, payload }) => {
  switch (type) {
    case 'update':
      return {
        value: payload.value,
        touched: true,
        error: payload.error,
      };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);
  console.log(state);
  return (
    <div>
      <input
        className={state.error ? 'error' : ''}
        value={state.value}
        onChange={(event) =>
          dispatch({
            type: 'update',
            payload: {
              value: event.target.value,
              error: state.touched ? event.target.value.length === 0 : null,
            },
          })
        }
      />
      <button onClick={() => dispatch({ type: 'reset' })}>reset</button>
    </div>
  );
};

export default Form;

Add a bit of rudimentary CSS to style the error class, and you have the beginning of an input with good UX and simple logic, thanks to useReducer:

.error {
  border-color: red;
}

.error:focus {
  outline-color: red;
}

Manage complex state

Another good use case for useReducer is when you have a LOT of different pieces of state, and putting them all in useState would get really out of hand.

We saw earlier an example of a single reducer managing 2 inputs with the same action. We can easily scale that example up to 4 inputs.

While we're doing this, we might as well refactor the action out of each individual input:

import { useReducer } from 'react';

const initialValue = {
  firstName: '',
  lastName: '',
  username: '',
  email: '',
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'update':
      return {
        ...state,
        [action.payload.key]: action.payload.value,
      };
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);

  const inputAction = (event) => {
    dispatch({
      type: 'update',
      payload: { key: event.target.name, value: event.target.value },
    });
  };

  return (
    <div>
      <input
        value={state.firstName}
        type="text"
        name="firstName"
        onChange={inputAction}
      />
      <input
        value={state.lastName}
        type="text"
        name="lastName"
        onChange={inputAction}
      />
      <input
        value={state.username}
        type="text"
        onChange={inputAction}
        name="username"
      />
      <input
        value={state.email}
        type="email"
        name="email"
        onChange={inputAction}
      />
    </div>
  );
};

export default Form;

Seriously, how clean and clear is that code? Imagine doing this with 4 useState instead! All right, it wouldn't be that bad, but this can scale to the number of inputs you want without adding anything else than the input itself.

And you could also easily build further on that. For example, we may want to add the touched and error property of the last section to each of the four inputs in this section.

In fact, I advise you to try it yourself, it's a good exercise to cement your learnings so far!

What about doing this but with `useState` instead?

One way to get rid of a dozen of useState statements is to just put all of your state into one object stored in a single useState, and then update that.

This solution works, and sometimes it's a good way to go. But you'll often find yourself re-implementing a useReducer in a more awkward way. Might as well use a reducer right away.

`useReducer` with TypeScript

All right, you should be getting the hang of useReducer now. If you're a TypeScript user, you're probably wondering how to properly make the two play nice.

Thankfully it's pretty easy. Here it is:

import { useReducer, ChangeEvent } from 'react';

type State = {
  firstName: string;
  lastName: string;
  username: string;
  email: string;
};

type Action =
  | {
      type: 'update';
      payload: {
        key: string;
        value: string;
      };
    }
  | { type: 'reset' };

const initialValue = {
  firstName: '',
  lastName: '',
  username: '',
  email: '',
};

const reducer = (state: State, action: Action) => {
  switch (action.type) {
    case 'update':
      return { ...state, [action.payload.key]: action.payload.value };
    case 'reset':
      return initialValue;
    default:
      throw new Error(`Unknown action type: ${action.type}`);
  }
};

const Form = () => {
  const [state, dispatch] = useReducer(reducer, initialValue);

  const inputAction = (event: ChangeEvent<HTMLInputElement>) => {
    dispatch({
      type: 'update',
      payload: { key: event.target.name, value: event.target.value },
    });
  };

  return (
    <div>
      <input
        value={state.firstName}
        type="text"
        name="firstName"
        onChange={inputAction}
      />
      <input
        value={state.lastName}
        type="text"
        name="lastName"
        onChange={inputAction}
      />
      <input
        value={state.username}
        type="text"
        onChange={inputAction}
        name="username"
      />
      <input
        value={state.email}
        type="email"
        name="email"
        onChange={inputAction}
      />
    </div>
  );
};

export default Form;

If you're unfamiliar with the syntax of the Action type, it's a discriminated union.

Redux: an overpowered `useReducer`

We're closing on the end of our useReducer guide (phew, it turned out way longer than I anticipated!). There's still one important thing to mention: Redux.

You might have heard of Redux as this very popular state management library. Some people hate it, some people love it. But it turns out that all your brain juice that went into understanding useReducer is useful to understand Redux.

In fact, you can think of Redux as just a big, global, managed and optimized useReducer for your entire app. It's really all it is.

You have a "store", which is your state, and you define "actions" that tell a "reducer" how to modify that store. Sounds familiar!

Of course there are some important differences, but if you've understood useReducer well you're in very good shape to understand Redux easily.

Wrap up

And that's the end of the article! I hope that it helped you learn everything you wanted about useReducer.

As you saw, it can be a very powerful tool in your React toolkit.

Good luck!

How to use React Context like a pro

Pierre Ouannes — Mon, 13 Sep 2021 19:04:29 +0000

Using React's Context API is often very useful. I've found that there are several patterns that you should regularly use in combination with contexts in React, and these patterns aren't that well known.

I'm sharing them in this article so you can start using React Contexts like a pro!

As a quick reminder before we start, here's the vanilla hook based implementation of a context (that we'll use as an example for the different patterns):

import React, { useContext, createContext, useState, useEffect } from 'react';

// create context
const UserContext = createContext(null);

const App = () => {
  // the value that will be given to the context
  const [user, setUser] = useState(null);

  // fetch a user from a fake backend API
  useEffect(() => {
    const fetchUser = () => {
      // this would usually be your own backend, or localStorage
      // for example
      fetch('https://randomuser.me/api/')
        .then((response) => response.json())
        .then((result) => setUser(result.results[0]))
        .catch((error) => console.log('An error occurred');
    };

    fetchUser();
  }, []);

  return (
    // the Provider gives access to the context to its children
    <UserContext.Provider value={user}>
      <Page />
    </UserContext.Provider>
  );
};

const Page = () => {
  // access the context value
  const user = useContext(UserContext);

  if (user?.login?.username) {
    return <p>You are logged in as {user?.login.username}</p>;
  } else {
    return <p>You are not logged in</p>;
  }
};

export default App;

In this example, the context is used to provide the logged-in user object to the app. This context is then consumed by the Page component that conditionally renders based on the user value.

This is a very common use case in real-life React applications.

Let's see how we can improve it.

Extract the React Context logic in another file

One thing I don't like in the code above is that the context logic is mixed in with the App code when both have little to do with each other. The App only wants to provide the context to its children and doesn't care about how this context is made.

So let's extract all of this logic to an external file.

Use React Context with a custom Provider

First, we'll create a UserContextProvider component inside of a new file called UserContext.jsx.

This component is the one that will hold the logic for getting the value of the context (user) and giving it to the UserContext.Provider:

import React, { createContext, useState, useEffect } from "react";

// create context
const UserContext = createContext(null);

const UserContextProvider = ({ children }) => {
  // the value that will be given to the context
  const [user, setUser] = useState(null);

  // fetch a user from a fake backend API
  useEffect(() => {
    const fetchUser = () => {
      // this would usually be your own backend, or localStorage
      // for example
      fetch("https://randomuser.me/api/")
        .then((response) => response.json())
        .then((result) => setUser(result.results[0]))
        .catch((error) => console.log("An error occured"));
    };

    fetchUser();
  }, []);

  return (
    // the Provider gives access to the context to its children
    <UserContext.Provider value={user}>
      {children}
    </UserContext.Provider>
  );
};

export { UserContext, UserContextProvider };

Now that we're removed the above from our App component, it's way cleaner:

import React, { useContext } from "react";

import { UserContext, UserContextProvider } from "./UserContext";

const App = () => {
  return (
    <UserContextProvider>
      <Page />
    </UserContextProvider>
  );
};

const Page = () => {
  // access the context value
  const user = useContext(UserContext);

  if (user?.login?.username) {
    return <p>You are logged in as {user?.login.username}</p>;
  } else {
    return <p>You are not logged in</p>;
  }
};

export default App;

Isn't it much nicer?

Use React Context with a custom hook

Unfortunately, there's still something bothering me in the code above.

In the Page component, we are accessing the context by using the useContext hook directly. But what if the component is not actually inside a UserContextProvider?

Then the value would default to undefined without us knowing. Of course, we could do a check for that in the Page component, but that means we would have to do it in every context consumer, which would get annoying.

It's much simpler to extract the useContext line to a custom hook, and we will do the check there.

Of course, you could argue that as our UserContextProvider is at the top-level of our app it's unlikely that a component would live outside of it.

Fair, but keep in mind that contexts aren't always at the top level. It's quite common for contexts to only be available in a section of the app, and in those cases it's quite easy to use a context where it's not available.

Another benefit to doing that is that it saves us an import. Instead of having to import both the useContext hook and the actual context itself (UserContext), we now only have to import the custom consumer hook. Fewer lines to write! 😄

Here's the resulting custom consumer hook:

// context consumer hook
const useUserContext = () => {
  // get the context
  const context = useContext(UserContext);

  // if `undefined`, throw an error
  if (context === undefined) {
    throw new Error("useUserContext was used outside of its Provider");
  }

  return context;
};

And to use it, simply import the hook and use it in the Page component:

const Page = () => {
  // access the context value
  const user = useUserContext();

  if (user?.login?.username) {
    return <p>You are logged in as {user?.login.username}</p>;
  } else {
    return <p>You are not logged in</p>;
  }
};

If you ask me, our context usage now seems very nice! All of the logic related to the UserContext sits in one file, the context is very simple to access using the useUserContext hook and we will be warned whenever we try to access the context outside of the right provider.

The code above is usually enough for most purposes, but sometimes you need to go further, usually for performance and optimization reasons.

The next two sections explore ways to optimize your context. Bear in mind that it should only be used if you are indeed having performance and optimization issues. Otherwise it's safe to go with the simpler option from above.

Be careful about updating context values, and memoize them

Imagine our UserContext in a big app. Presumably, a lot of components are using the context.

Now imagine that we are polling our backend every 15 seconds to see if the user value changed somehow. For example we could be storing the number of credits a user has left in his account directly in the user object.

Want to learn how to do something every 15 seconds in a React app? You do it using intervals!

If we do this naively, it means that every single component which uses that context will re-render every 15 seconds. Not great.

You might say that polling your backend every 15 seconds for this info and storing it in the user object isn't the best way to go about doing this.

And you would be right. However, this situation and others like it frequently happen in production, where things aren't always ideal.

This exact issue happened in my team a few months ago. Knowing how to avoid that problem is an important part of knowing how to effectively use context API in React.

Let's see how to avoid that.

Memoize values in your context with `useMemo` and `useCallback`

It's usually a good idea to wrap context values with memoizing functions like useMemo and useCallback.

Context values are often used in dependency arrays in context consumers. If you don't memoize context values, you can end up with unwanted behaviors like useEffect triggering unnecessarily.

A change in those values could trigger dependency arrays in every context consumer, so it can have a sizeable impact on the affected components. And memoizing the value in the context is very effective since you only have to memoize the value once and it will work for all the components consuming the context.

Here is more information on dependency arrays if you are not sure about how they work.

For example, let's say you have a signout function inside the context. It's best to wrap it in a useCallback hook:

const UserContextProvider = ({ children }) => {
  // the value that will be given to the context
  const [user, setUser] = useState(null);

  // sign out the user, memoized
  const signout = useCallback(() => {
    setUser(null);
  }, []);

  // fetch a user from a fake backend API
  useEffect(() => {
    const fetchUser = () => {
      // this would usually be your own backend, or localStorage
      // for example
      fetch("https://randomuser.me/api/")
        .then((response) => response.json())
        .then((result) => setUser(result.results[0]))
        .catch((error) => console.log("An error occured"));
    };

    fetchUser();
  }, []);

  return (
    // the Provider gives access to the context to its children
    <UserContext.Provider value={{ user, signout }}>
      {children}
    </UserContext.Provider>
  );
};

Keep in mind that memoizing won't always prevent unnecessary triggers. For example, the user variable is an object. If you change that object through a setState, as far as useMemo is concerned the object is a new one (even if all the keys and the values are the same). This is because React is only doing a shallow equality test in dependency arrays.

In that case, you should do the check yourself and only update the context value if necessary. To do that you could for example use Lodash's isEqual function that deeply compares two javascript objects.

Separate state and state setters (if necessary)

To be clear, you usually don't need to do this. If you're careful about updating context values and they are memoized, you're very probably fine.

But sometimes you might run into issues that will be solved by separating context state and context state setters.

Here's what I mean by "context state" and "context state setter".

In our last example you have the user object, which is the "context state", and the signout function, which is a "context state setter": it's used to change the "context state".

Both don't need to be in the same provider. For example, a log-out button might only need the signout function without caring about the current state of authentication.

In the default case, that button would update every time the user object changes, because a change in the user object means a change in the context value which means an update to every consumer of the context.

In situations where you care about this (and only in those), you can separate your state and your state setters in two different contexts.

I believe this idea was first introduced by Kent C. Dodds in this blog post.

The implementation of that pattern is the following:

import React, {
  createContext,
  useContext,
  useState,
  useEffect,
  useCallback
} from "react";

// create contexts
const UserContextState = createContext(null);
const UserContextUpdater = createContext(null);

// context consumer hook
const useUserContextState = () => {
  // get the context
  const context = useContext(UserContextState);

  // if `undefined`, throw an error
  if (context === undefined) {
    throw new Error("useUserContextState was used outside of its Provider");
  }

  return context;
};

// context consumer hook
const useUserContextUpdater = () => {
  // get the context
  const context = useContext(UserContextUpdater);

  // if `undefined`, throw an error
  if (context === undefined) {
    throw new Error("useUserContextUpdater was used outside of its Provider");
  }

  return context;
};

const UserContextProvider = ({ children }) => {
  // the value that will be given to the context
  const [user, setUser] = useState(null);

  const signout = useCallback(() => {
    setUser(null);
  }, []);

  // fetch a user from a fake backend API
  useEffect(() => {
    const fetchUser = () => {
      // this would usually be your own backend, or localStorage
      // for example
      fetch("https://randomuser.me/api/")
        .then((response) => response.json())
        .then((result) => setUser(result.results[0]))
        .catch((error) => console.log("An error occured"));
    };

    fetchUser();
  }, []);

  return (
    // the Providers gives access to the context to its children
    <UserContextState.Provider value={user}>
      <UserContextUpdater.Provider value={signout}>
        {children}
      </UserContextUpdater.Provider>
    </UserContextState.Provider>
  );
};

export { UserContextProvider, useUserContextState, useUserContextUpdater };

The usage is very similar to before, as you can guess. You just have to choose to access the state or the state setters (or both). Of course if you often need both you can also create a hook that provides both out of the box, thus reproducing the previous behavior.

···
const Page = () => {
  // access the context value
  const user = useUserContextState();

  if (user?.login?.username) {
    return <p>You are logged in as {user?.login.username}</p>;
  } else {
    return <p>You are not logged in</p>;
  }
};
···

Only use React Context if you really need it

React Context is a great tool, but it can also be dangerous. As it's usually shared between a bunch of components, it can cause performance issues when abused and used for the wrong kind of state.

Most of the time, useState is enough for your needs. It's important to know when to use useState and when to use useContext. And it's not a clear division either; sometimes both work well.

You want useState to be your default option for state and only switch to useContext if it's necessary.

A good reason to switch to contexts is if the state is accessed by a lot of components.

Bear in mind that to solve the "prop drilling" issue where you are passing props through layers of components, there are other strategies you can also use.

Examples of good purposes of context:

Share the authentication state across your app
Share a theme across your app
Share a value that is used by a lot of components in a part of your app (for example the current balance of a user in a dashboard where a lot of components are using that balance)

Wrap up

Voilà! You're now equipped to improve your usage of React Contexts. As you saw, there are a lot of different ways to go about it, and the one you choose really depends on your exact circumstances.

So part of getting good at using React Contexts is also just building experience and reflecting on your code once in a while, to see if you should have done things differently.

Good luck!

React Events and Typescript: a complete guide

Pierre Ouannes — Sat, 04 Sep 2021 19:07:53 +0000

Events are everywhere in React, but learning how to properly use them and their handlers with TypeScript can be surprisingly tricky. There are several ways to do it, some better than others.

In this article we'll cover all kinds of events in TypeScript: click, form, select, input, ... First we'll see how to type events on a toy example, then I'll show you how to type any event.

Let's dive in!

Our toy example

To show how to type events in React, we'll use the following example:

import { useState } from 'react';

export default function App() {
  const [inputValue, setInputValue] = useState('');

  const handleInputChange = (event) => {
    setInputValue(event.target.value);
  };

  const handleClick = (event) => {
    console.log('Submit button clicked!');
  };

  return (
    <div className="App">
      <h1>Hello World</h1>
      <input value={inputValue} onChange={handleInputChange} />
      <button onClick={handleClick}>Submit</button>
    </div>
  );
}

It's a very simple React app with an input field and a submit button. But if you're using TypeScript with this code, it must be screaming all kinds of obscenities right now! Don't worry, we're about to see how to set it at ease.

Note that we don't really use handleClick's' argument in this code, so you could just omit it and TypeScript would be happy. But I've included it anyway just to show how you would type if you'd had a use for it.

Don't worry if you'd like to know about other events than those two. This code will be used as an example, then we'll see how to type any event afterwards.

Adding in TypeScript

There are several ways to type the above code, and we'll see the 3 main ones. There are:

Typing the event handler argument
Typing the event handler itself
Relying on inferred types

Typing the event

Let's start with typing the onClick event. This one is quite straightforward. React provides a MouseEvent type you can directly use!

import { useState, MouseEvent } from 'react';

export default function App() {
  const [inputValue, setInputValue] = useState('');

  const handleInputChange = (event) => {
    setInputValue(event.target.value);
  };

  const handleClick = (event: MouseEvent) => {
    console.log('Submit button clicked!');
  };

  return (
    <div className="App">
      <h1>Hello World</h1>
      <input value={inputValue} onChange={handleInputChange} />
      <button onClick={handleClick}>Submit</button>
    </div>
  );
}

The onClick event is actually generated by React itself: it's a synthetic event. A synthetic event is a React wrapper around the native browser event, to always have the same API regardless of differences in browsers.

Let's move on to the handleInputChange function.

It's pretty similar to handleClick, with a significant difference. You also import a type directly from react, which this time is called ChangeEvent. The difference is that ChangeEvent is a Generic type to which you have to provide what kind of DOM element is being used.

Not sure what Generics are? Here is TypeScript's guide to them. You can think about it as a type function that accepts one or more arguments, to enable the user of the generic to customize the exact type.

The result is the following:

import { useState, ChangeEvent, MouseEvent } from 'react';

export default function App() {
  const [inputValue, setInputValue] = useState('');

  // the type variable must match the DOM element emitting the
  // event, an `input` in this case
  const handleInputChange = (event: ChangeEvent<HTMLInputElement>) => {
    setInputValue(event.target.value);
  };

  const handleClick = (event: MouseEvent) => {
    console.log('Submit button clicked!');
  };

  return (
    <div className="App">
      <h1>Hello World</h1>
      <input value={inputValue} onChange={handleInputChange} />
      <button onClick={handleClick}>Submit</button>
    </div>
  );
}

One thing to note in the code above is that HTMLInputElement refers specifically to HTML's input tag. If we were using a textarea, we would be using HTMLTextAreaElement instead.

And there you have it! You made TypeScript happy 😁

Note that MouseEvent is also a Generic type, so you can restrict it if necessary. For example, let's restrict the above MouseEvent to specifically be a mouse event emanating from a button.

const handleClick = (event: MouseEvent<HTMLButtonElement>) => {
  console.log('Submit button clicked!');
};

Typing the event handler

Instead of typing the event itself, as we did above, we can also type the functions themselves.

It looks very similar, and it's mostly a matter of taste. I find typing the event more flexible so I tend to use the first one, but being aware of this other option is always good.

import { useState, ChangeEventHandler, MouseEventHandler } from 'react';

export default function App() {
  const [inputValue, setInputValue] = useState('');

  // the type variable must match the DOM element emitting the
  // event, an `input` in this case
  const handleInputChange: ChangeEventHandler<HTMLInputElement> = (event) => {
    setInputValue(event.target.value);
  };

  const handleClick: MouseEventHandler = (event) => {
    console.log('Submit button clicked!');
  };

  return (
    <div className="App">
      <h1>Hello World</h1>
      <input value={inputValue} onChange={handleInputChange} />
      <button onClick={handleClick}>Submit</button>
    </div>
  );
}

Relying on inferred types

Lastly, you can also rely on inferred types and not type anything yourself. For this, you need to inline your callbacks, which isn't always what you want to do.

import { useState } from 'react';

export default function App() {
  const [inputValue, setInputValue] = useState('');

  return (
    <div className="App">
      <h1>Hello World</h1>
      <input
        value={inputValue}
        onChange={(event) => setInputValue(event.target.value)}
      />
      <button onClick={(event) => console.log('Submit button clicked!')}>
        Submit
      </button>
    </div>
  );
}

Other React events

Of course, there's a lot of other events than the two shown above.

A good way to find the complete list supported by React is to have a peak at the type definitions, in the React typings source code itself!

Form Events

Building forms is very common in web development. We already saw how to handle text inputs, let's now see an example (directly taken from React's docs on forms) of a select, as well as a form submit events.

import { useState, ChangeEvent, FormEvent } from 'react';

export default function App() {
  const [selectValue, setSelectValue] = useState('coconut');

  const handleSubmit = (event: FormEvent) => {
    console.log('Form was submitted!');
  };

  const handleChange = (event: ChangeEvent<HTMLSelectElement>) => {
    setSelectValue(event.target.value);
  };

  return (
    <div className="App">
      <h1>Hello World</h1>
      <form onSubmit={handleSubmit}>
        <label>
          Pick your favorite flavor:
          <select value={selectValue} onChange={handleChange}>
            <option value="grapefruit">Grapefruit</option>
            <option value="lime">Lime</option>
            <option value="coconut">Coconut</option>
            <option value="mango">Mango</option>
          </select>
        </label>
        <input type="submit" value="Submit" />
      </form>
    </div>
  );
}

As you can see, it looks very similar to our first example.

Keyboard Events

Lastly, let's see an example of handling keyboard events since those are also quite common!

import { useState, useEffect } from 'react';

export default function App() {
  const [key, setKey] = useState('');

  useEffect(() => {
    // handle what happens on key press
    const handleKeyPress = (event: KeyboardEvent) => {
      setKey(event.key);
    };

    // attach the event listener
    document.addEventListener('keydown', handleKeyPress);

    // remove the event listener
    return () => {
      document.removeEventListener('keydown', handleKeyPress);
    };
  }, [handleKeyPress]);

  return (
    <div className="App">
      <h2>Try typing on a key</h2>
      <p>Key typed: {key}</p>
    </div>
  );
}

Want to learn how to implement a fully functioning keyboard shortcut in your app? Check out this article!

Wrap up

I hope this article clears up how to handle events with React and Typescript! As you can see, it's pretty simple once you know how to do it.

DEV Community: Pierre Ouannes

React & TypeScript: how to type hooks (a complete guide)

Rely on type inference if you can

When to not rely on type inference

Inferred type is too permissive

The inferred type is wrong

How to type useState

How to type useReducer

How to type the reducer state

How to type the reducer action

How to type useRef

How to type useRef for mutable values

How to type useRef for DOM nodes

Bonus: how to type forwardRef

How to type useEffect and useLayoutEffect

How to type useMemo and useCallback

How to type React contexts

Bonus: how to type custom hooks

Wrap up

React & TypeScript: use generics to improve your types

What are generics in TypeScript?

Why generics can be very useful

Multiple type variables

Generics syntax for arrow functions in JSX

A word of warning on type variable names

Bonus: a generic type example from open source: useState itself!

Using generics in React

Generic types for React hooks like useState

Generic types for Component props

Wrap up

How to use React useReducer hook like a pro

What is React useReducer hook and how to use it

useState and useReducer: a quick comparison

useReducer: a backend mental model

How does the reducer work

How does the dispatch function work?

useReducer initial state

useReducer tips and tricks

The reducer should throw an error for unknown action types

You should spread the state in every action

Stick to the conventional action structure

Sugar syntax: deconstruct type and payload from action

useReducer third parameter: lazy initialization

useState vs useReducer: when to use which

Multiple pieces of state that rely on each other

Manage complex state

What about doing this but with useState instead?

useReducer with TypeScript

Redux: an overpowered useReducer

Wrap up

How to use React Context like a pro

Extract the React Context logic in another file

Use React Context with a custom Provider

Use React Context with a custom hook

Be careful about updating context values, and memoize them

Memoize values in your context with useMemo and useCallback

Separate state and state setters (if necessary)

Only use React Context if you really need it

Wrap up

React Events and Typescript: a complete guide

Our toy example

Adding in TypeScript

Typing the event

Typing the event handler

Relying on inferred types

Other React events

Form Events

Keyboard Events

Wrap up

How to type `useState`

How to type `useReducer`

How to type `useRef`

How to type `useRef` for mutable values

How to type `useRef` for DOM nodes

Bonus: how to type `forwardRef`

How to type `useEffect` and `useLayoutEffect`

How to type `useMemo` and `useCallback`

Bonus: a generic type example from open source: `useState` itself!

Generic types for React hooks like `useState`

What is React `useReducer` hook and how to use it

`useState` and `useReducer`: a quick comparison

`useReducer`: a backend mental model

`useReducer` initial state

`useReducer` tips and tricks

Sugar syntax: deconstruct `type` and `payload` from action

`useReducer` third parameter: lazy initialization

`useState` vs `useReducer`: when to use which

What about doing this but with `useState` instead?

`useReducer` with TypeScript

Redux: an overpowered `useReducer`

Memoize values in your context with `useMemo` and `useCallback`