DEV Community

Nadia Makarevich
Nadia Makarevich

Posted on • Updated on • Originally published at developerway.com

The mystery of React Element, children, parents and re-renders

Image description

Originally published at https://www.developerway.com. The website has more articles like this šŸ˜‰


In one of the previous articles about React composition, I showed an example of how to improve performance of a component with heavy state operations by passing other components to it as children instead of rendering them directly. This article received a question, which sent me into another investigative spiral on how React works, which in turn at some point made me doubt everything that I know about React and even question my own sanity for a short while. Children are not children, parents are not parents, memoization doesnā€™t work as it should, life is meaningless, re-renders control our life and nothing can stop them (spoiler alert: I emerged victorious from it šŸ˜…).

Intrigued I hope? šŸ˜‰ Let me explain.

The ā€œchildrenā€ pattern and a few mysteries

The pattern itself goes like this: imagine you have some frequent state changes in a component. For example, the state is updated in onMouseMove callback.

const MovingComponent = () => {
  const [state, setState] = useState({ x: 100, y: 100 });

  return (
    <div
      // when the mouse moves inside this component, update the state
      onMouseMove={(e) => setState({ x: e.clientX - 20, y: e.clientY - 20 })}
      // use this state right away - the component will follow mouse movements
      style={{ left: state.x, top: state.y }}
    >
      <ChildComponent />
    </div>
  );
};
Enter fullscreen mode Exit fullscreen mode

Now, we know that React components re-render themselves and all their children when the state is updated. In this case, on every mouse move the state of MovingComponent is updated, its re-render is triggered, and as a result, ChildComponent will re-render as well. If the ChildComponent is heavy, its frequent re-renders can cause performance problems for your app.

The way to fight this, other than React.memo, is to extract ChildComponent outside and pass it as children.

const MovingComponent = ({ children }) => {
  const [state, setState] = useState({ x: 100, y: 100 });

  return (
    <div onMouseMove={(e) => setState({ x: e.clientX - 20, y: e.clientY - 20 })} style={{ left: state.x, top: state.y }}>
      // children now will not be re-rendered
      {children}
    </div>
  );
};
Enter fullscreen mode Exit fullscreen mode

And compose those two components together like this:

const SomeOutsideComponent = () => {
  return (
    <MovingComponent>
      <ChildComponent />
    </MovingComponent>
  );
};
Enter fullscreen mode Exit fullscreen mode

The ChildComponent ā€œbelongsā€ to the SomeOutsideComponent now, which is a parent component of MovingComponent and not affected by the state change in it. As a result, it wonā€™t be re-rendered on every mouse move. See the codesandbox with both examples.

Mystery1: but wait, they are still children!. They are rendered inside a div that changes its style on every mouse move <div style={{ left: state.x, top: state.y }}>, i.e. this div is the parent that re-renders. Why exactly children donā€™t re-render here? šŸ¤”

It gets even more interesting.

Mystery2: children as a render function. If I pass children as a render function (a common pattern for cross-components data sharing), ChildComponent starts re-rendering itself again, even if it doesnā€™t depend on the changed state:

const MovingComponent = ({ children }) => {
  ...
  return (
    <div ...// callbacks same as before
    >
      // children as render function with some data
      // data doesn't depend on the changed state!
      {children({ data: 'something' })}
    </div>
  );
};

const SomeOutsideComponent = () => {
  return (
    <MovingComponent>
      // ChildComponent re-renders when state in MovingComponent changes!
      // even if it doesn't use the data that is passed from it
      {() => <ChildComponent />}
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

But why? It still ā€œbelongsā€ to the SomeOutsideComponent component, and this one doesnā€™t re-render šŸ¤” Codesandbox with the example.

Mystery 3: React.memo behavior. What if I introduce some state to the outside component SomeOutsideComponent and try to prevent re-renders of its children with React.memo? In the ā€œnormalā€ parent-child relationship just wrapping MovingComponent with it is enough, but when ChildComponent is passed as children, it still re-renders, even if MovingComponent is memoized!

// wrapping MovingComponent in memo to prevent it from re-rendering
const MovingComponentMemo = React.memo(MovingComponent);

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  return (
    <MovingComponentMemo>
      <!-- ChildComponent will still re-render when SomeOutsideComponent re-renders -->
      <ChildComponent />
    </MovingComponentMemo>
  )
}
Enter fullscreen mode Exit fullscreen mode

It works though if I memoize just ChildComponent without its parent:

// wrapping ChildComponent in memo to prevent it from re-rendering
const ChildComponentMemo = React.memo(ChildComponent);

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  return (
    <MovingComponent>
      <!-- ChildComponent won't re-render, even if the parent is not memoized -->
      <ChildComponentMemo />
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

See codesandbox.

Mystery4: useCallback hook behavior. But when I pass ChildComponent as a render function, and try to prevent its re-renders by memoizing that function, it just doesnā€™t work šŸ˜¬

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  // trying to prevent ChildComponent from re-rendering by memoising render function. Won't work!
  const child = useCallback(() => <ChildComponent />, []);

  return (
    <MovingComponent>
      <!-- Memoized render function. Didn't help with re-renders though -->
      {child}
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

See codesandbox.

Can you solve those mysteries now, without looking further into the answers? šŸ˜‰

If you decided you want to know the answers right now, a few key concepts we need to understand first, before jumping into the solutions.

What exactly are React ā€œchildrenā€?

First of all, what exactly are ā€œchildrenā€, when they are passed like this?

const Parent = ({ children }) => {
  return <>{children}</>;
};

<Parent>
  <Child />
</Parent>;
Enter fullscreen mode Exit fullscreen mode

Well, the answer is simple - they are just a prop. The fact that weā€™re accessing them through the rest of the props kinda gives it away šŸ˜

const Parent = (props) => {
  return <>{props.children}</>;
};
Enter fullscreen mode Exit fullscreen mode

The fancy ā€œcompositionā€ pattern that we use is nothing more than a syntax sugar for our convenience. We can even re-write it to be a prop explicitly, it will be exactly the same:

<Parent children={<Child />} />
Enter fullscreen mode Exit fullscreen mode

And same as any other prop, we can pass components there as Elements, Functions, or Components - this is where the ā€œrender function in childrenā€ pattern comes from. We can totally do this:

// as prop
<Parent children={() => <Child />} />

// "normal" syntax
<Parent>
  {() => <Child />}
</Parent>

// implementation
const Parent = ({ children }) => {
  return <>{children()}</>
}
Enter fullscreen mode Exit fullscreen mode

or even this:

<Parent children={Child} />;

const Parent = ({ children: Child }) => {
  return <>{<Child />}</>;
};
Enter fullscreen mode Exit fullscreen mode

Although the last one probably shouldnā€™t do, no one on your team will appreciate it.

See this article for more details on those patterns, how they work and the re-renders related caveats: React component as prop: the right wayā„¢ļø

In a way, this gives us the answer to the mystery number one, if the answer ā€œcomponents passed as ā€œchildrenā€ donā€™t re-render since they are just propsā€ is acceptable.

What is React Element?

The second important thing to understand is what exactly is happening when I do this:

const child = <Child />;
Enter fullscreen mode Exit fullscreen mode

Quite often people assume that this is how components are rendered, and this is when the rendering cycle for the Child component kicks in. This is not true.

<Child /> is what is called an ā€œElementā€. This is nothing more than syntax sugar again for a function React.createElement that returns an object. And this object is just a description of the things you want to see on the screen when this element actually ends up in the render tree. Not sooner.

Basically, if I do this:

const Parent = () => {
  // will just sit there idly
  const child = <Child />;

  return <div />;
};
Enter fullscreen mode Exit fullscreen mode

child constant will be just a constant that contains an object that just sits there idly.

You can even replace this syntax sugar with a direct function call:

const Parent = () => {
  // exactly the same as <Child />
  const child = React.createElement(Child, null, null);

  return <div />;
};
Enter fullscreen mode Exit fullscreen mode

See codesandbox.

Only when I actually include it in the return result (which is a synonym for ā€œrender those stuffā€ in functional components), and only after Parent component renders itself, will the actual render of Child component be triggered.

const Parent = () => {
  // render of Child will be triggered when Parent re-renders
  // since it's included in the return
  const child = <Child />;

  return <div>{child}</div>;
};
Enter fullscreen mode Exit fullscreen mode

Updating Elements

Elements are immutable objects. The only way to update an Element, and trigger its corresponding component re-render, is to re-create an object itself. This is exactly what is happening during re-renders:

const Parent = () => {
  // child definition object will be re-created.
  // so Child component will be re-rendered when Parent re-renders
  const child = <Child />;

  return <div>{child}</div>;
};
Enter fullscreen mode Exit fullscreen mode

If the Parent component re-renders, the content of the child constant will be re-created from scratch, which is fine and super cheap since itā€™s just an object. child is a new Element from React perspective (we re-created the object), but in exactly the same place and exactly the same type, so React will just update the existing component with the new data (re-render the existing Child).

And this is what allows memoization to work: if I wrap Child in React.memo

const ChildMemo = React.memo(Child);

const Parent = () => {
  const child = <ChildMemo />;

  return <div>{child}</div>;
};
Enter fullscreen mode Exit fullscreen mode

or memoize the result of the function call

const Parent = () => {
  const child = useMemo(() => <Child />, []);

  return <div>{child}</div>;
};
Enter fullscreen mode Exit fullscreen mode

the definition object will not be re-created, React will think that it doesnā€™t need updating, and Childā€™s re-render wonā€™t happen.

React docs give a bit more details on how all of this works if you fancy an even deeper dive: Rendering Elements, React Without JSX, React Components, Elements, and Instances.

Resolving the mysteries

Now, that we know all of the above, itā€™s very easy to resolve all the mysteries that triggered this investigation. Key points to remember:

  1. When weā€™re writing const child = <Child />, weā€™re just creating an Element, i.e. component definition, not rendering it. This definition is an immutable object.
  2. Component from this definition will be rendered only when it ends up in the actual render tree. For functional components, itā€™s when you actually return it from the component.
  3. Re-creating the definition object will trigger the corresponding componentā€™s re-render

And now to the mysteries' solutions.

Mystery 1: why components that are passed as props donā€™t re-render?

const MovingComponent = ({ children }) => {
  // this will trigger re-render
  const [state, setState] = useState();
  return (
    <div
      // ...
      style={{ left: state.x, top: state.y }}
    >
      <!-- those won't re-render because of the state change -->
      {children}
    </div>
  );
};

const SomeOutsideComponent = () => {
  return (
    <MovingComponent>
      <ChildComponent />
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

ā€œchildrenā€ is a <ChildComponent /> element that is created in SomeOutsideComponent. When MovingComponent re-renders because of its state change, its props stay the same. Therefore any Element (i.e. definition object) that comes from props wonā€™t be re-created, and therefore re-renders of those components wonā€™t happen.

Mystery 2: if children are passed as a render function, they start re-rendering. Why?

const MovingComponent = ({ children }) => {
  // this will trigger re-render
  const [state, setState] = useState();
  return (
    <div ///...
    >
      <!-- those will re-render because of the state change -->
      {children()}
    </div>
  );
};

const SomeOutsideComponent = () => {
  return (
    <MovingComponent>
      {() => <ChildComponent />}
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

In this case ā€œchildrenā€ are a function, and the Element (definition object) is the result of calling this function. We call this function inside MovingComponent, i.e. we will call it on every re-render. Therefore on every re-render, we will re-create the definition object <ChildComponent />, which as a result will trigger ChildComponentā€™s re-render.

Mystery 3: why wrapping ā€œparentā€ component in React.memo won't prevent the "child" from outside re-render? And why if ā€œchildā€ is wrapped in it, there is no need to wrap the parent?

// wrapping MovingComponent in memo to prevent it from re-rendering
const MovingComponentMemo = React.memo(MovingComponent);

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  return (
    <MovingComponentMemo>
      <!-- ChildComponent will re-render when SomeOutsideComponent re-renders -->
      <ChildComponent />
    </MovingComponentMemo>
  )
}
Enter fullscreen mode Exit fullscreen mode

Remember that children are just props? We can re-write the code above to make the flow clearer:

const SomeOutsideComponent = () => {
  // ...
  return <MovingComponentMemo children={<ChildComponent />} />;
};
Enter fullscreen mode Exit fullscreen mode

We are memoizing only MovingComponentMemo here, but it still has children prop, which accepts an Element (i.e. an object). We re-create this object on every re-render, memoized component will try to do the props check, will detect that children prop changed, and will trigger re-render of MovingComponentMemo. And since ChildComponentā€™s definition was re-created, it will trigger its re-render as well.

And if we do the opposite and just wrap ChildComponent:

// wrapping ChildComponent in memo to prevent it from re-rendering
const ChildComponentMemo = React.memo(ChildComponent);

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  return (
    <MovingComponent>
      <!-- ChildComponent won't be re-rendered anymore -->
      <ChildComponentMemo />
    </MovingComponent>
  )
}
Enter fullscreen mode Exit fullscreen mode

In this case, MovingComponent will still have ā€œchildrenā€ prop, but it will be memoized, so its value will be preserved between re-renders. MovingComponent is not memoized itself, so it will re-render, but when React reaches the ā€œchildrenā€ part, it will see that definition of ChildComponentMemo hasnā€™t changed, so it will skip this part. Re-render wonā€™t happen.

See the codesandbox.

Mystery 4: when passing children as a function, why memoizing this function doesnā€™t work?

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  // this memoization doesn't prevent re-renders of ChildComponent
  const child = useCallback(() => <ChildComponent />, []);

  return <MovingComponent>{child}</MovingComponent>;
};
Enter fullscreen mode Exit fullscreen mode

Letā€™s first re-write it with ā€œchildrenā€ as a prop, to make the flow easier to understand:

const SomeOutsideComponent = () => {
  // trigger re-renders here with state
  const [state, setState] = useState();

  // this memoization doesn't prevent re-renders of ChildComponent
  const child = useCallback(() => <ChildComponent />, []);

  return <MovingComponent children={child} />;
};
Enter fullscreen mode Exit fullscreen mode

Now, what we have here is: SomeOutsideComponent triggers re-render. MovingComponent is its child, and itā€™s not memoized, so it will re-render as well. When it re-renders, it will call the children function during re-render. The function is memoized, yes, but its return is not. So on every call, it will call <ChildComponent />, i.e. will create a new definition object, which in turn will trigger re-render of ChildComponent.

That flow also means, that if we want to prevent ChildComponent from re-renders here, we have two ways to do that. We either need to memoize the function as it is now AND wrap MovingComponent in React.memo: this will prevent MovingComponent from re-rendering, which means the ā€œchildrenā€ function never will be called, and ChildComponent definition will never be updated.

OR, we can remove function memoization here, and just wrap ChildComponent in React.memo: MovingComponent will re-render, ā€œchildrenā€ function will be triggered, but its result will be memoized, so ChildComponent will never re-render.

And indeed, both of them work, see this codesandbox.

That is all for today, hope you enjoyed those little mysteries and will have full control over who renders what next time you write components āœŒšŸ¼

...

Originally published at https://www.developerway.com. The website has more articles like this šŸ˜‰

Subscribe to the newsletter, connect on LinkedIn or follow on Twitter to get notified as soon as the next article comes out.

Top comments (2)

Collapse
 
dmitriialekseevfs profile image
Dmitrii Alekseev

So useful. I write on React pretty long, but found some new revelations:) Thanks a lot!

Collapse
 
snowyang profile image
Snow YĆ”ng • Edited

As a self-taught developer who have to work next week for him first dev job in his life, I found tremendous value in your post! Thank you!