State Container Components

Published 1-7-2022 ∙ Last updated 31-12-2022 ∙ v2.0.0

In React, state should be kept as close to where relevant as possible ¹. Placing state unnecessarily high in the component tree can lead to , even more so when that state updates often.

When performance suffers, a component can be decomposed to isolate frequently updating state and by consequence, renders. That can mean moving some oft-changing state and the parts that need it down into a new component. It’s a way of colocating state and the UI elements that depend on it to make your React app faster.

Decomposing doesn’t exclusively mean moving down to a new, small leaf component, it comes in many shapes. Keep an eye open for unrelated states in a single component and try to find the fault lines between states and the JSX it ends up in, compose components accordingly.

are React components that hold some state to isolate it, such that rerenders are are avoided in parts of the UI that don’t need to know about said state.

If you can’t find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common parent component.

Thinking in React: Identify where your state should

Let’s see what this means in practice. We got a <NavBar/> component with all the usual navbar stuff and an app-wide loading indicator, a spinner that pops up whenever something is being fetched (f.e. using react-query’s useIsFetching).

function NavBar({ currentUser, sidebarOpen, toggleSidebar }) {
  const isFetching = useIsFetching();
  const [openMenu, setOpenMenu] = useState(null); 
  return (
    <nav>
      <SidebarButton sidebarOpen={sidebarOpen} onClick={toggleSidebar} />
      
      <Logo />
      
      {Boolean(isFetching) ? <Spinner /> : null}
      
      <NotificationIcon onClick={() => setOpenMenu("notifications")}/>
      
      {openMenu === "notifications" && <Notifications setOpenMenu={setOpenMenu} />}
      <div onClick={() => setMenuOpen("user")}>
        Logged in as {currentUser.name}
        <Avatar image={currentUser.img} />
      </div>
      {openMenu === "user" && <UserMenu setOpenMenu={setOpenMenu} />}
    </nav>
  );
}

Note that the often changing isFetching state is not relevant to the other children of the navbar. It is, however, causing them to rerender everytime it’s toggled. Only <Spinner/> needs to know about isFetching.

To isolate the renders, make a new component and move <Spinner/> and isFetching down into it. Admittedly it’s very small, normally it wouldn’t be worth making a component for it. In this case, extracting it to a component is worth it because it holds the oft-changing isFetching state and therefore frequent rerenders in the <Navbar/> are avoided.

// Component just to hold `isFetching` state, a State Container Component!
function FetchingSpinner() {
  const isFetching = useIsFetching();
  return Boolean(isFetching) ? (
    <Spinner />
  ) : null;
}

Let’s suppose we have a chart component with two states:

The state of the current pointer coordinates to show a hover line with tooltip
A selection state to select data.

The pointer coordinates change often while the selection does not.

x: 0, y: 284

Selected data

Here’s what the code looks like roughly.

const allData = { A: ..., B: ... }; // Imagine actual data in here
function Chart() {
  const [selected, setSelected] = useState("A");
  const [pointerCoords, setPointerCoords] = useState({ x: 0, y: 0 });
  const data = allData[selected];
  const hoverValue = getHoverValue(data, pointerCoords);
  return (
    <div>
      <Select selected={selected} setSelected={setSelected} />
      <svg
        onPointerMove={(event) => {
          // calculate chart coordinates here
          setPointerCoords({ x: point.x, y: point.y });
        }}
      >
        {/* `data` depends on `selected` */}
        <Axes data={data} />
        <Line data={data} />
        <Hover
          x={pointerCoords.x}
          y={pointerCoords.y}
          selected={selected}
          hoverValue={hoverValue}
        />
      </svg>
    </div>
  );
}

Half of these component do not need to know about the pointer coords but will still rerender whenever the pointer is moved. This .

Keep state as close to where it’s relevant as possible

Kent C. Dodds - Prop Drilling

Let’s break it down. <Axes /> and <Line /> depend on selected state, so does <Select /> which of course sets it. The function for onPointerMove on the <svg> sets the pointer coords state. At last, <Hover/> needs both states.

It helps to draw a quick diagram for these things, text surely isn’t the best way to explain it. Give it a quick try!

The problem here is that the pointer coords state is placed ‘too high’. <Hover/> needs both though, so we can’t move it down, right?

If you can’t find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common parent component.

Thinking in React: Identify where your state should

We can in fact move it down! Simply move the components (the subtree) that needs the pointerCoords state into a new component that only holds that state; what I like to call a “State Container Component”.

We can make use of React’s composable nature to nest inside a state container component from the outside using the children prop. Move <svg> and its child <Hover/> to a separate component that holds the pointer coords state and wrap it around the components that don’t need it. Now the other components will not rerender when it is updated, it’s just a matter of good composition!

// ChartSvg is a 'state container component'!
function ChartSvg({ children, data, selected }) {
  const [pointerCoords, setPointerCoords] = useState({ x: 0, y: 0 });
  const hoverValue = getHoverValue(data, pointerCoords);
  return (
    <svg
      onPointerMove={(event) => {
        const point = ... // calculate chart coordinates here
        setPointerCoords({ x: point.x, y: point.y });
     }}>
      {children} {/* <Axes /> and <Line /> will be rendered here */}
      <Hover
        x={pointerCoords.x}
        y={pointerCoords.y}
        selected={selected}
        hoverValue={hoverValue}
      />
    </svg>
  );
}
export function Chart() {
  const [selected, setSelected] = useState("A");
  const data = rawData[selected];
  ... // chart things here
  return (
    <div>
      <Select selected={selected} setSelected={setSelected} />
      <ChartSvg
        data={data}
        selected={selected}
      >
        <Axes data={data} />
        <Line data={data} />
      </ChartSvg>
    </div>
  );
}

Selected data

And finally, here's a diagram that summarizes it. The green triangle represent the selected state and the blue square represents the pointerCoords state. I hope it clears things up a little.

Component hierarchy diagram showing before and after using a state container component for the previously given demo code

I recommend you to use the React dev tools with the "Highlight updates when components render." setting on and play around with both charts to see the differences. And finally, always measure before moving code in the name of performance!

Thinking in React in the React docs
Application State Management with React by Kent C. Dodds.
Using Composition in React to Avoid "Prop Drilling" by Micheal Jackson

Moving State Down

Splitting a Component using children

Further Reading & Watching

Footnotes