
First, a little back story. Should you build a small personal website/blog in React? Probably not. Is it overkill? Absolutely. Hear me out though and I may change your mind.

Years ago my personal website was built on [Jekyll](https://jekyllrb.com/) and hosted on [GitHub Pages](https://pages.github.com/). It was a pretty simple setup with the most annoying part being installing Ruby on my Windows machine to build and run locally. Eventually I improved that with a simple [Docker](https://www.docker.com/) container. There wasn't much content on my site and I seldom touched it, so this approach served me well for quite a while.

Over time my attention and experience began to become more [React](https://reactjs.org/)-centric. I eventually had people asking why my personal site wasn't written in React. It was an easy answer: I didn't need it. React makes building dynamic, interactive user interfaces a breeze, but my site had none of that. Plus, I wanted my site to be hosted as static content and easily indexable, so client-side rendering wasn't a good option. In more recent years though, React began to be used in static site generators like [Gatsby](https://www.gatsbyjs.com/) and those concerns were addressed. React was now more like a template language, just like Jekyll has Liquid. At that point I didn't have a reason _not_ to switch to Gatsby. I could use the technology I am most familiar with, avoid the question of why my site is not built in that technology, and still have efficient hosting.

The conversion was not trivial though. I decided to modernize my site while migrating it and rebuilt it from scratch. I also switched from hosting on GitHub Pages to [Netlify](https://www.netlify.com/), though that was actually the easiest part. Getting Gatsby configured the way I wanted proved more difficult than I had anticipated, especially having a depth of React experience to lean on. I found myself fighting plugin configurations and piecing together articles I had found from searching until I finally landed on a setup that worked, but was far from what I wanted. The most difficult problem I remember having was getting two different sets of Markdown processed, one for my blog and the other for project pages. Those needed to be displayed separately with different templates. I got it to work, but I wasn't happy with the confusing setup.

Despite the annoyances I kept my site on Gatsby for a couple years. This year, however, a former Gatsby employee described how Gatsby treated their employees, particularly calling out how they approached diversity. This conversation initially started on [Twitter](https://twitter.com/tesseralis/status/1293649007739191296) and lead to an [open letter](https://gist.github.com/gatsbyjs-employees/5b08b884be088bce54abaf4f980fbf7b) to the community from many Gatsby employees acknowledging the issues. While Gatsby has promised improvement, this sparked me to reconsider the technology behind my personal site. It didn't take much convincing given the annoyances I have already mentioned, so I started evaluating the state of other options.

[Next.js](https://nextjs.org/) stood out as the clear front-runner to me. Their static site generation had matured in the time since my last site rebuild and easily checked all of my requirements. The greatest selling point was the reliance on regular JavaScript/Node.js to do things like process markdown and generate pages. Rather than showing off how I could configure Gatsby plugins 🤮, I can show off my JavaScript skills. The most annoying part of my Gatsby setup, blog posts vs projects in Markdown, became trivial. In fact, after I committed to switching, I had the site switched over in a few hours. The result can be seen in the pull request [here](https://github.com/rtbenfield/tylerbenfield.me/pull/8).

There are still a few things I'm working out. Favicon generation from a single image would be excellent, but I'm trying to find a plain JavaScript approach that doesn't rely on something like a Webpack plugin (though I may cave and take that approach). I also gave up my ServiceWorker, but I didn't particularly need it to begin with.

Overall I am extremely satisfied with Next.js and would recommend it to anyone looking to build a static site in React. I can't speak as much to server-side apps, though I've heard great things about that too. Keep an eye on [Remix](https://remix.run/) as an alternative as well. Michael and Ryan have put a lot of thought and years of experience into that project and I expect big things from it, though I probably won't migrate my site again without some big selling points.


Migrating my site to Next.js


React's [Context API](https://reactjs.org/docs/context.html) is extemely versatile and provides an excellent primitive for building on top of. That said, I've found that many experienced React developers are still looking for a pattern for using context that they like. I thought I'd share my approach, particularly for shared-state contexts.

```tsx
import * as React from "react";

// Define a type for the context result
// Note that the state is a field within this type and you need a container type with set functions
export interface MyContext {
  // You can have any number of fields here and any type
  someState: string;
  // Make sure to have a callback version if you need to compute from previous state
  setSomeState(value: string): void;
}

// I don't normally export context so that it can't be consumed outside of this file
// Also, add null or undefined here unless there is a reasonable default (typically not for shared-state)
const context = React.createContext<MyContext | null>(null);
// Be sure to set displayName for better debugging
context.displayName = "MyContext";

// Export a provider that sets up the shared state
export const MyContextProvider: React.FC = ({ children }) => {
  const [someState, setSomeState] = React.useState<string>("");
  const value: MyContext = {
    someState,
    setSomeState,
  };
  return <context.Provider value={value}>{children}</context.Provider>;
};

// Export a hook to consume the context
// This is nice for controlling how the context is used
export function useMyContext(): MyContext {
  const value = React.useContext(context);
  // Check for null/undefined to see if provider was used
  if (!value) {
    // Throw an error to fail early if used improperly
    throw new Error(
      "useMyContext can only be used in a descendent of MyContextProvider",
    );
  } else {
    // value can't be null/undefined
    return value;
  }
}

// If needed, you can export a HOC or render prop (context.Consumer) version as well
// I typically avoid that and only use hooks unless absolutely necessary
```

That's it! I've got a few more tips to go along with this though.

First, avoid having multiple set functions that would typically be called back-to-back. Multiple state updates can less efficient and cause unnecessary rerenders. Instead, pull those kind of values into a single `useState` call and expose functions on the context for easily setting the values together. The API you expose on the context type does not have to be identical to `useState`, so play around and find an API that makes the most sense for your use case.

Second, take some time to learn about `useDispatch` and how it compares to `useState`. For more complex workflows or those that resemble state machines, you can expose a strongly-typed `dispatch` function on your context value instead of set functions. This can help address the multiple set calls from the previous tip while also preventing invalid states.

Finally, if your shared-state is typically set by a component that does not consume the value (a scenario I've found is rare), you can further optimize by having separate context instances for setters and getters. Kent C. Dodds has a great blog post on this called [How to use React Context Effectively](https://kentcdodds.com/blog/how-to-use-react-context-effectively). Kent's approach eliminates unnecessary rerenders in components that only need the setters and not the state values themselves.

I hope sharing my approach to using React Context for shared state has been helpful!


How I use React Context


React provides a great way to gracefully handle errors using [error boundaries](https://reactjs.org/docs/error-boundaries.html).
The drawback of error boundaries, which is noted in a big warning right in the docs, is that they only catch errors in `render`.
How many of our errors actually occur in `render`? From my experience, I'd say most don't.
They typically occur in event handlers or asynchronous code, especially when we are thinking of errors that we can't prevent
like failed network calls.
With some clever tricks we can expand the power of error boundaries to handle those cases and a lot more!

## Simple Error Boundary

Let's start by writing a simple error boundary for our examples.
Error boundaries are super easy to create.
We start with a normal class component (function components are not yet supported as error boundaries),
and use `componentDidCatch(error, errorInfo)` to catch any errors that occur in `render`.
`componentDidCatch` is a great place to send our errors to a reporting service or log them ourselves,
but React has a better method for updating our error boundary component state for displaying a fallback UI.
By implementing `static getDerivedStateFromError(error)` in our component, we can return a state update based on the error that was thrown.
Here's a simple example straight from the React docs.

```jsx
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children;
  }
}
```

Now we can wrap any of our components, or even our entire app, in our `ErrorBoundary` component to catch errors within that component tree.
We can even nest `ErrorBoundary` components to isolate subtrees and stop the error from propagating further.

## Simple Event Handler Error

The React docs on error boundaries show an example of how we can handle event handlers and asynchronous code with a simple `try` / `catch`.
We can put the error in state and then use it in `render` to show a fallback display.
No magic, no error boundary, just using simple React primitives.

```jsx
const MyComponent = () => {
  const [error, setError] = React.useState(null);

  function handleClick() {
    try {
      // Do something that could throw
    } catch (err) {
      setError(err);
    }
  }

  if (error) {
    return <h1>Caught an error.</h1>;
  } else {
    return <div onClick={handleClick}>Click Me</div>;
  }
};
```

That's great, but what if we don't want all of our components to deal with errors themselves?
Ideally, the `ErrorBoundary` component we defined above could be reused along with its fallback UI and error reporting.
We have to use it anyway to handle errors in `render`, so we might as well take full advantage of it.
So what do we do?

## Mind Blowing Section

Just re-throw the error in `render`. **What?!?** Yup. Check it out.

```jsx
const MyComponent = () => {
  const [error, setError] = React.useState(null);
  if (error) {
    throw error;
  }

  function handleClick() {
    try {
      // Do something that could throw
    } catch (err) {
      setError(err);
    }
  }

  return <div onClick={handleClick}>Click Me</div>;
};
```

That's all it takes. No magic, no special syntax, no utility functions, just plain JavaScript.
The error object contains all of the stack trace information from when it was created,
so we don't even lose or pollute our stack trace by doing this.
This simple trick will propagate the error up to the closest error boundary to be handled.

We can do it with anything else that gives us an error as well.
For example, take a theoretical `useFetchedData` hook that does some asynchronous data fetching.
As long as it returns an error object as part of its results, we can throw it during render.

> Side note: I strongly recommend you **do not** throw event handler or async errors like this in your own custom hooks.
> Instead, return an object that contains the result of the code and an optional error.
> Let the component consuming the hook be responsible for throwing. This provides maximum flexibility to hook consumers and keeps the hook unopinionated.

## Conclusion

To sum all of this up, you can make React error boundaries way more powerful by just rethrowing event handler and async errors during `render`.
With this simple trick it is incredibly easy to make our React application more fault tolerant, making our users happy as a result.


Easy React Error Handling


React Context is often used to pass values down a component tree and, among other things, avoid prop drilling.
Something I haven't seen it used for much, however, is passing values back up.
It turns out there are some elegant APIs that can be built by using Context in situations that may not seem obvious at first.

## Schema Building

How many times have you been working with a component that has requires a large object for configuration?
Scenarios that immediately come to my mind are things like a data table or chart configuration that require have nested configuration options.
For some reason, building these large objects in React components just doesn't feel natural or right to me.
It feels like going back to the jQuery days of `$(selector).doSomeCoolStuff({ blah blah blah })`.
After having implemented one of these APIs myself I wanted to find a better way, and Context is a perfect fit.

Context is a very primitive API that is unopinionated about _what_ the value is that you are passing down.
That value can be some state you want to share among that component tree, but it could just as well be an object with various functions attached.
Those functions can be a way for consumers to reach back up to the parent and provide it with information about what the child would like to do.
You might say that's bad practice and the child should not be aware of its parent, and in most cases it is,
but any context consumer is inherently aware that is must be under a provider.

With that concept in mind, let's rethink our big configuration object example.
I usually like to start by thinking about what the API surface (props) of my component look like.
Maybe we have a component that displays charts like this:

```js
const MyApp = () => {
  return (
    <Chart
      data={data}
      charts={[
        {
          color: "blue",
          dataKey: "value1",
          plotPoints: "hover",
          tooltip: {
            formatter: (v) => formatValue(v),
          },
          type: "line",
        },
        {
          color: "red",
          dataKey: "value2",
          plotPoints: "hover",
          tooltip: {
            formatter: (v) => formatValue(v),
          },
          type: "line",
        },
      ]}
    />
  );
};
```

This is a pretty small example, but you can imagine how much more complex it gets as the number of options increases.
What would this API look like if were more component-based?
We might have something more like this:

```js
const MyApp = () => {
  return (
    <Chart data={data}>
      <LineChart
        color="blue"
        dataKey="value1"
        plotPoints="hover"
        tooltip={{
          formatter: (v) => formatValue(v),
        }}
      />
      <LineChart
        color="red"
        dataKey="value2"
        plotPoints="hover"
        tooltip={{
          formatter: (v) => formatValue(v),
        }}
      />
    </Chart>
  );
};
```

Doesn't that read better? Well, maybe that's a matter of preference, but it does open the door for some pretty powerful reusability.
If all of the configuration "parts" are components, nothing is stopping us from using other tools React gives us with components.
We might define a reusable `LineChart` configuration like this:

```js
const MyLineChart = (props) => {
  return (
    <LineChart
      color="blue"
      plotPoints="hover"
      tooltip={{
        formatter: (v) => formatValue(v),
      }}
      {...props}
    />
  );
};

const MyApp = () => {
  return (
    <Chart data={data}>
      <MyLineChart dataKey="value1" />
      <MyLineChart color="red" dataKey="value2" />
    </Chart>
  );
};
```

We could even tie it into other things, like Context, to use themes or translations:

```js
const MyLineChart = (props) => {
  const { formatValue } = useLocalizationContext();
  const { getChartColor } = useTheme();
  return (
    <LineChart
      color={getChartColor(props.dataKey)}
      plotPoints="hover"
      tooltip={{
        formatter: (v) => formatValue(v),
      }}
      {...props}
    />
  );
};

const MyApp = () => {
  return (
    <Chart data={data}>
      <MyLineChart dataKey="value1" />
      <MyLineChart dataKey="value2" />
    </Chart>
  );
};
```

This is only scratching the surface!
You have all the power of React components at your disposal!
That includes things like effects and state.

Cool! But how? Of course the answer is Context!

Let's start with our Context definition.
The Context will stay as internal knowledge to our chart module.
That means it won't be evident at all in using our API, which will keep things nice and clean.
We're also going to create a custom provider component that will provide the functions we need and manage the state.
What state do we have? Take a look:

```js
const chartContext = React.createContext();

export const ChartContextProvider = ({ children }) => {
  const [charts, setCharts] = React.useState([]);

  const registerChart = React.useCallback((chart) => {
    // Make up a random ID for this chart object and return it for unregistering later
    const id = Math.random();
    setCharts((prev) => [...prev, { ...chart, id }]);
    return id;
  }, []);

  const unregisterChart = React.useCallback((id) => {
    setCharts((prev) => prev.filter((x) => x.id !== id));
  }, []);

  // Build our actual context value object
  const value = React.useMemo(() => {
    return {
      charts,
      registerChart,
      unregisterChart,
    };
  }, [charts, registerChart, unregisterChart]);

  return (
    <chartContext.Provider value={value}>{children}</chartContext.Provider>
  );
};

// Convenience hook so that chartContext is not exposed outside this module
export function useChartContext() {
  const value = React.useContext(chartContext);
  if (!value) {
    // Oops! We tried to use a chart component (ex. LineChart) without wrapping it in a Chart
    throw new Error("Chart components cannot be used without Chart wrapper");
  }
  return value;
}
```

What good does this give us? Let's start using it in `Chart` and `LineChart`.

```js
export const Chart = ({ children, data }) => {
  return (
    <ChartContextProvider>
      {/* children will contain the LineChart instances */}
      {children}
      <ChartDisplay data={data} />
    </ChartContextProvider>
  );
};

export const LineChart = ({ color, dataKey, plotPoints, tooltip }) => {
  const { registerChart, unregisterChart } = useChartContext();

  // Any time one of the props changes, re-register the chart object definition
  React.useEffect(() => {
    const id = registerChart({
      color,
      dataKey,
      plotPoints,
      tooltip,
    });
    return () => unregisterChart(id);
  }, [color, dataKey, plotPoints, tooltip]);

  // LineChart doesn't actually render anything!
  return null;
};

const ChartDisplay = ({ data }) => {
  const { charts } = useChartContext();

  // TODO: Draw the actual chart using the `charts` object and `data`
};
```

That's all there is to it!
You might be wondering where the `ChartDisplay` component came from.
This is a component internal to our `Chart` module that is used to access the chart context value
and read the chart definitions supplied by `LineChart`.
It has to exist under the `ChartContextProvider` component tree, but no code outside of this module will ever know it exists.
It also provides a nice separation of concerns where each component has a designated responsibility.

Of course there are always "gotchas".
We should be cautious of the side effects of unregistering and registering the chart object each time a property changes and what that implies for `ChartDisplay`.
If you're options are changing frequently or dynamically, you may want a function to update an existing chart.
In that case, you can place the `id` in a React Ref for use in a separate `useEffect` hook that calls the update function.

## UI Controls

Another powerful way we can use the flexibility of Context is in communication between UI controls.
Say we want to build a component that displays a tab strip, manages the selected tab, and displays the selected tab's content.
Just like above, let's start with what we want the API surface to look like:

```js
const MyApp = () => {
  const [selectedTab, setSelectedTab] = React.useState(1);
  return (
    <Tabs onChange={setSelectedTab} selectedTab={selectedTab}>
      <Tab tabKey={1} label="Profile">
        <Profile />
      </Tab>
      <Tab tabKey={2} label="Messages">
        <Messages />
      </Tab>
      <Tab tabKey={3} label="Friends">
        <Friends />
      </Tab>
    </Tabs>
  );
};
```

That seems simple, but how does the `Tabs` component know when our `Tab` is clicked?
We could have a prop on `Tab` for selected, but then we have to repeat it on each `Tab`, repeat the `setSelectedTab` for each `Tab`,
and ensure that there is no case where two tabs have `selected={true}` at the same time.
This feels like the right API, so let's use Context to make it happen!

```js
const tabContext = React.createContext();

const TabContextProvider = ({ children, onChange, selectedTab }) => {
  const [tabs, setTabs] = React.useState([]);

  const registerTab = React.useCallback((tab) => {
    setTabs(prev => [...prev, tab]);
  }, []);

  const unregisterTab = React.useCallback((tabKey) => {
    setTabs(prev => prev.filter(x => x.tabKey !== tabKey));
  }, []);

  // Build our actual context value object
  const value = React.useMemo(() => {
    return {
      registerTab,
      selectedTab,
      setSelectedTab: onChange,
      tabs,
      unregisterTab,
    };
  }, [onChange, registerTab, selectedTab, tabs, unregisterTab]);

  return (
    <tabContext.Provider value={value}>
      {children}
    </tabContext.Provider>
  )
};
// Convenience hook so that chartContext is not exposed outside this module
export function useTabContext() {
  const value = React.useContext(tabContext);
  if (!value) {
    // Oops! We tried to use a Tab component outside of Tabs
    throw new Error("Tab components cannot be used without Tabs wrapper");
  }
  return value;
}

const Tabs = ({ children, onChange, selectedTab }) => {
  return (
    <TabContextProvider onChange={onChange} selectedTab={selectedTab}>
      <TabDisplay />
      {children}
    <TabContextProvider>
  );
};

const Tab = ({ children, label, tabKey }) => {
  const { registerTab, unregisterTab, selectedTab } = useTabContext();

  React.useEffect(() => {
    registerTab({
      label,
      tabKey,
    });
    return () => unregisterTab(tabKey);
  }, [label, tabKey]);

  // Tab only renders children if it is selected
  if (selectedTab === tabKey) {
    return children;
  } else {
    return null;
  }
};

const TabDisplay = () => {
  const { tabs, selectedTab, setSelectedTab } = useTabContext();

  // TODO: Display tab strip using `tabs`
};
```

Notice how similar this was to the chart example.
This pattern can be used for a variety of situations with only a few minor adjustments.

The biggest "gotcha" here is we may want to consider adding some safeguards around tab ordering if our tab definitions will be changing.
Because of unregistering then registering to the end of the array, we may end up accidentally reordering tabs.
This could be solved with an `updateTab` option or an `order` prop, depending on how you prefer to handle it.

> Readers that have been deeper into React may wonder why we don't just map over the children with React's Children APIs.
> That's definitely a possibility, but enforces a lot of unnecessary limitations.
> The most annoying that I have encountered is that the children "inspection" is only one level deep,
> preventing you from wrapping your `Tab` components in other components or making reusable `Tab` components.
> Context, on the other hand, is agnostic of the component tree depth so long as a `Tab` component is eventually rendered.

## Wrapping Up

What can we take away from this? React Context is flexible, and can be used in ingenious ways to solve problems that were not easily solvable before.
Before you accept a suboptimal API for your component, consider if Context would help you get the API you want.


React Context Registration Model


The biggest benefit and curse of React is how flexible it is.
In most cases, React provides us with primitive tools and leaves it to us to compose them ourselves.
This is great for large projects that require flexibility, but can be confusing if you are new to React.
It also doesn't help that there is a lot of misinformation on the web, not from malicious intent of the author but simply from lack of a full undestanding of how React works.

I've heard a lot of people recently saying that React Context can lead to performance issues.
I'm a big supporter of using Context and have not experienced performance problems with using it,
so I did some searching and read a few articles that discussed the performance problems.
All of the articles I read were using Context in inefficient ways that would absolutely lead to unnecessary rerenders.
I thought it would be best to demonstrate how to use Context in efficient ways and hopefully debunk some of the myths spreading on the web.

## What is React Context?

First things first, React Context is a way to provide values from a parent component to its children without directly passing it through props.
With Context, the parent supplies the value to a "provider" component that wraps any children that will need that value.
The children can then subscribe to the context using either the "consumer" component or the `useContext` hook that is now available.
Context is vastly beneficial when you have values that need to be shared across a large component tree and almost a necessity if you have intermediary components that are unaware of the dependency on the context value and therefore could not pass the value as a prop (more on that in a later post).
It does come with the trade-off of indirection. Once you use Context, you may have to trace up the component tree to find where the "provider" is that supplies the value, rather than following the props chain.
This article isn't intended to dive into when you should use context, but if you are new to the API I recommend reading the [React Docs](https://reactjs.org/docs/context.html).

## When does React rerender?

In order to be aware of the performance of our React applications, its best to have a basic understanding of when react rerenders components.
For most cases, React rerenders a component on a state change in that component or one of its ancestors.
So if all of your state is managed at the root component of your application, every change will rerender all of the components you have.
That sounds terribly innefficient, but React renders are very performant and a rerender does not necessarily mean the DOM is updated.
There are also ways to skip rerendering parts of the component tree using `React.memo`, `React.PureComponent`, or `shouldComponentUpdate`, but that's not the focus of this article.
Instead we are just going to use this as a benchmark for Context.
We want to ensure that our use of Context causes fewer rerenders and not more.

## How do we track rerenders?

There are a few ways to track rerenders, but the simplest approach that we will use for this article is simply `console.log` in the components we want to track.
Function components we can simply `console.log` in the function body, while class components can `console.log` in the `render` function.

## Baseline with State

Let's start with a baseline using only React state. We'll use a todo list example to keep things simple.
The CodeSandbox example below has 3 components:

- `TodoList` is the "root" and holds the state of all todo items.
- `TodoListItem` displays a single todo item. It has no state of its own, but updates the parent state through callback props.
- `AddTodo` contains a form for adding a new todo. It owns the state of the form, but communicates the new item to `TodoList` when it is submitted.
- `Header` is just a simple component that lives outside of `TodoList` to show that it doesn't rerender on state changes in `TodoList`.

Each component and function has `console.log` added to track rerenders.
Play around with adding and updating items and observe the Console tab below the preview.

<iframe src="https://codesandbox.io/embed/bitter-wave-1yv1g?expanddevtools=1&fontsize=14&module=%2Fsrc%2FTodoList.jsx" title="react-context-performance-example1" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

There are a few things to notice from the logs in this baseline example.

First, any input to the field in `AddTodo` rerenders only that component.
As mentioned earlier, state updates rerender that component and everything **below**, not above.

Second, when a todo is added, updated, or removed, not only do all `TodoListItem` components rerender, but so does `AddTodo`.
This may seem weird since nothing in `AddTodo` relies on `todos`, but that is how React works by default.
Because state updated in `TodoList`, and `AddTodo` is a child of `TodoList`, it gets rerendered on a state update in `TodoList`.

Finally, notice that `Header` only renders once. Because it lives above `TodoList` it is not affected by the state updates.

## Introducing Context

Now let's implement React Context as a replacement for the state in `TodoList`.
We can copy the same code from `TodoList` into a new component that will act as the Context value provider.
The new component, which I've called `TodoContextProvider` can then wrap the entire app in `index.js`.
Once that is done, any component in the app can use the `useTodos` hook to access the context value.
Notice how fewer props we have being passed around now. Each component instead subscribes itself to the Context value.

> Using Context for something this simple is absolutely overkill, but this is just an example.
> I'm not suggesting you go switch all of your state to Context.

<iframe src="https://codesandbox.io/embed/react-context-performance-example1-hf9uq?expanddevtools=1&fontsize=14&module=%2Fsrc%2FtodoContext.jsx" title="react-context-performance-example2" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

Notice that this didn't eliminate any component renders. In fact, it added the `TodoContextProvider` render.
That's because all of our components are subscribing to the context value with `useTodos`.
Even if they didn't, the "root" `TodoList` component subscribes to it, so the rerender that happens there will cascade to the other components anyway.

`Header` still doesn't rerender though even though it is underneath `TodoContextProvider`.
Even with the state updates happening, it does not cascade the rerender to `Header`.
We are even providing a new value object on every rerender of `TodoContextProvider`.
This shows us that React is smart enough not to rerender _all_ components beneath `TodoContextProvider`, just those that subscribe to the Context value.

So Context hasn't made anything worse (the added `TodoContextProvider` is negligible), but it also hasn't helped our performance.
In a large app we couldn't benefit from improved maintainability and reduced prop-drilling though, so going this far is not for nothing.
Let's go a bit deeper though and explore some ways to skip unnecessary rerenders.

## Skipping Rerenders

> Remember how I said this was overkill for our todo list? Well this is extreme overkill.
> I would only recommend going this far if you have already implemented context and are having **measurable** performance concerns.
> Also, why are your renders so slow? Try to improve that first and it will have a greater overall benefit on your app.

We can start by improving the referential integrity of the Context value.
In our previous example, the three update functions we provided were declared as new function references on every render of `TodoContextProvider`.
That's probably not a big performance issue in itself, but prevents us from relying on referential integrity to skip rerendering.
We can fix that by wrapping them in `useCallback`, which will only give us a new function reference if one of the dependencies changes.
In our case we have no dependencies (`setTodos` is guaranteed to remain consistent, and also why we use the callback version), so we will only ever make one copy of each of these functions.

That alone doesn't help us though. It just allows us to take the next step.
`AddTodo` doesn't actually rely on the todos themselves, just the `addTodo` function.
Let's first lift `AddTodo` to be rendered in `index.js` instead of by `TodoList` so that it is unaffected by `TodoList` rerenders.
If `AddTodo` is **expensive** to rerender, we can wrap the component in `React.memo` which will only rerender on a prop, state, or context value change.
This is only a shallow compare though, which is why immutability is important.
In the case of `AddTodo`, our context value is changing, but we are only concerned with one function out of it.
We can take advantage of that by wrapping another component around `AddTodo` that connects to `useTodos` and only passes the `addTodo` function to `AddTodo` as a prop.
By doing this we remove the `useTodos` dependency from `AddTodo` itself, and `React.memo` will check the referential integrity of our new prop and skip rerendering!
To be fair, we haven't reduced the _number_ of rerenders, but we did exchange an expensive rerender for an inexpensive one.
All of this can be done within the internal scope of `AddTodo.jsx` and none of the other components in the tree know the difference.

<iframe src="https://codesandbox.io/embed/react-context-performance-example2-2u1lp?expanddevtools=1&fontsize=14&module=%2Fsrc%2FtodoContext.jsx" title="react-context-performance-example3" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

Let's keep going! What if we don't want to rerender all `TodoListItem` (again, **only if it is expensive**) components for a change to a single item, like changing `isComplete`?
We can take a similar approach to subscribe to `TodoListItem` to a single todo item.
By wrapping `TodoListItem` in another component that extracts the values we need from `useTodos` and passes them as props, we can rely on `React.memo` to skip rerendering.
As long as the `todo` prop's reference is maintained, we skip rerendering `TodoListItem`!
This **only** works because of our use of immutability in `updateTodo`.
Otherwise, we would have just introduced a bug because `TodoListItem` would not have rerendered changes made to the item!

<iframe src="https://codesandbox.io/embed/react-context-performance-example3-2fuh0?expanddevtools=1&fontsize=14&module=%2Fsrc%2FTodoListItem.jsx" title="react-context-performance-example4" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media; usb" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

## Redux didn't need this!

Actually, it did. Redux requires you to connect to your global store using selectors and `connect`.
That `connect` function directly relates to our `AddTodoContainer` and `TodoListItemContainer` components from above.
In fact, if you look in the React DevTools, you'll see that Redux introduces `Connect(AddTodo)` and `Connect(TodoListItem` components in our tree.
We could easily write a `connect` utility function that selected from our context and did the same thing, we have just been a bit more explicit.
Using components instead of `connect` also allows us to take advantage of other React things, like using `React.useMemo` instead of `reselect` to avoid heavy recomputations.
Additionally, Redux requires you to use immutability for it to prevent unnecessary rerenders of your connected components,
something we also accomplished with `React.memo` and the same immutability limitations.

## Wrapping Up

What should we take away from all of this?
The performance of React Context is dependent on how we just it, just like many other things we use.
I don't recommend replacing all of your state with Context, or going as far as we did with preventing rerenders,
but having these tools and knowledge gives us the upper hand if we encounted performance problems and need to address them.
You should always benchmark and exhaust render optimizations first before implementing these more extreme performance tricks.
If you have any questions about Context, other material here, or have found anything incorrect about what I've said, please drop me an email and let me know!


Tyler Benfield

Blog

Migrating my site to Next.js

How I use React Context

Easy React Error Handling

React Context Registration Model

React Context Performance