
Hi, React developers!

In my previous [post](/blog/react-rerender), we explored the mechanics of re-renders and how to fix performance issues
by "moving state down." We solved the "slow modal" problem by isolating the state into a smaller component, leaving the
rest of the heavy app alone.

But what happens when you can't move the state down?

Imagine you are that same developer at a FAANG company. You’ve just optimized the modal, but now your PM asks for a new
feature: a "scroll progress" block that wraps the entire main content area.

## The Problem

The requirements are strict:

* A block that tracks the scroll position.
* It wraps `VerySlowComponent`, `BunchOfStuff`, and `OtherStuffAlsoComplicated`.
* As you scroll, a small UI element inside the wrapper needs to move/animate based on that scroll position.

Your first instinct might be to wrap everything in a div with an onScroll handler (or maybe try to hide the logic in
a [custom hook](/blog/react-hooks-pitfalls), which often doesn't help):

```jsx
const App = () => {
  // We need this state for the moving block
  const [scrollPosition, setScrollPosition] = useState(0);

  const handleScroll = (e) => {
    setScrollPosition(e.target.scrollTop);
  };

  return (
    <div className="scrollable-block" onScroll={handleScroll}>
      <MovingBlock position={scrollPosition} />

      {/* 😱 These will re-render on EVERY scroll event! */}
      <VerySlowComponent />
      <BunchOfStuff />
      <OtherStuffAlsoComplicated />
    </div>
  );
};
```

<Image src="elements.png" alt="" />

If you run this, the app will crawl. Every pixel you scroll triggers a state update in `App`. Since `App` re-renders,
React re-renders everything inside it. The "moving state down" trick won't work easily here because the `div` wraps the
content. The state needs to be high up.

Is `React.memo` the only escape hatch? No. There is a more elegant composition pattern that relies on understanding the
difference between a Component and an Element.

## The Solution: Children as Props

Let’s extract that scroll logic into its own component, but with a twist. Instead of hard-coding the slow components
inside, we accept them as children.

```jsx
const ScrollableWithMovingBlock = ({ children }) => {
  const [position, setPosition] = useState(0);

  const handleScroll = (e) => {
    setPosition(e.target.scrollTop);
  };

  return (
    <div className="scrollable-block" onScroll={handleScroll}>
      <MovingBlock position={position} />
      {children}
    </div>
  );
};
```

Now, we rewrite our `App`:

```jsx
const App = () => {
  return (
    <ScrollableWithMovingBlock>
      {/* These are now passed as props! */}
      <VerySlowComponent />
      <BunchOfStuff />
      <OtherStuffAlsoComplicated />
    </ScrollableWithMovingBlock>
  );
};
```

Result: The scroll animation is buttery smooth. The heavy components do not re-render, even though they appear "inside"
the component that is updating 60 times a second.

## Why does this work? (The Deep Dive)

To understand this, we need to distinguish between a **Component** and an **Element**.

A **Component** is a function (e.g., `App` or `ScrollableWithMovingBlock`).

An **Element** is an object that describes what to render (e.g., `{ type: 'div', props: ... }`).

When `App` renders, it creates the elements for `<VerySlowComponent />` and its friends. It passes these Element objects
to `ScrollableWithMovingBlock` via the `children` prop.

Now, look at the render timeline:

1. **User Scrolls**: `ScrollableWithMovingBlock` updates its position state.
2. **Re-render**: `ScrollableWithMovingBlock` re-executes its function.
3. **The Return**: It returns a new `div` with the new `MovingBlock`. But for `{children}`, it uses the exact same
   reference it received from `App`.
4. **Reconciliation**: React looks at the `children` prop. It asks: "Did this object change?"
5. **The Check**: Since `App` (the owner) didn't re-render, the children object is referentially identical (`===`).
   React sees this and says, "Okay, no need to touch this subtree."

## Syntax Sugar

It's important to remember that `children` is just a prop like any other. The "nesting" syntax is just JSX sugar.
Creating an element is just a [JavaScript expression](/blog/expressions-statements), not a statement. This code:

```jsx
<Parent>
  <Child />
</Parent>
```

Is strictly equivalent to this:

```jsx
<Parent children={<Child />} />
```

You could even name the prop `content` or `body` if you wanted. As long as the Element object is created in the parent
scope (which isn't re-rendering) and passed down, the child will be preserved.

## Summary

In the previous article, we fixed performance by [moving state down](/blog/react-rerender#moving-state-down) into a
child. Today we fixed it by passing the heavy UI down as props.

Both strategies achieve the same goal: separating the part that changes from the part that remains static.



Learn how React elements work and how passing children as props can optimize performance by preventing unnecessary re-renders.

React Elements, Children as Props, and Re-Renders


### Understanding the Hidden Pitfalls of Custom Hooks in React

In a previous post we covered [How React Rerenders Works](/blog/react-rerender). But today, we'll take a closer look at
the hidden pitfalls of custom hooks in React.

<Image alt="Hand-drawn diagram showing 'Custom React Hooks' as the main title with small hook illustrations, 'useEffect ( )' written in blue text on the left, and the React logo (atomic symbol) in blue on the bottom right." src="hooks.jpg" priority={true} />

When we handle state, component re-renders, and application performance in React, custom hooks are a powerful tool that
help us keep our components clean and manageable. However, this simplicity can sometimes hide performance issues that we
may not immediately notice.

Consider a basic custom hook for toggling the visibility of a tooltip:

```jsx
const useTooltipToggle = () => {
  const [visible, setVisible] = useState(false);

  return {
    visible,
    show: () => setVisible(true),
    hide: () => setVisible(false),
  };
};
```

Using this hook in a component might look neat and clean:

```jsx
const App = () => {
  const {
    visible,
    show,
    hide
  } = useTooltipToggle();

  return (
    <div className="app-container">
      <button onMouseEnter={show} onMouseLeave={hide}>Hover me!</button>
      {visible && <Tooltip text="Hello, Tooltip!" />}
      <HeavyComputationComponent />
      <AnotherIntensiveComponent />
    </div>
  );
};
```

At first glance, this setup appears elegant—state logic neatly wrapped in the `useTooltipToggle` hook. However, this
approach hides a subtle performance issue: whenever the tooltip visibility state changes, React re-renders the entire
`App` component, despite the state being limited to a small interaction.

> Why? You can read more about react rerenders [here](/blog/react-rerender).

### Hidden States and Re-rendering Pitfalls

Let's extend our custom hook to listen for a scroll event:

```jsx
const useTooltipToggle = () => {
  const [scrollPosition, setScrollPosition] = useState(window.scrollY);

  useEffect(() => {
    const handleScroll = () => setScrollPosition(window.scrollY);
    window.addEventListener('scroll', handleScroll);

    return () => window.removeEventListener('scroll', handleScroll);
  }, []);

  return {
    // For example, this part of the code was simplified
    visible: false,
    show: () => {},
    hide: () => {},
  };
};
```

Now, every time the user scrolls, this hook updates the state internally. Even though the scrolling position isn't
returned or directly used, it **triggers state changes**, causing the entire `App` to re-render unnecessarily.

### Nested Hooks Can Multiply Issues

The problem worsens when custom hooks depend on other hooks indirectly. For example, consider another hook for tracking
mouse movement:

```jsx
const useMouseTracker = () => {
  const [mousePosition, setMousePosition] = useState({
    x: 0,
    y: 0
  });

  useEffect(() => {
    const updateMousePosition = (e) => setMousePosition({
      x: e.clientX,
      y: e.clientY
    });
    window.addEventListener('mousemove', updateMousePosition);

    return () => window.removeEventListener('mousemove', updateMousePosition);
  }, []);

  return null;
};

const useTooltipToggle = () => {
  useMouseTracker();

  return {
    // For example, this part of the code was simplified
    visible: false,
    show: () => {},
    hide: () => {},
  };
};
```

Even if `useTooltipToggle` does not directly use mouse position state, the `App` component still re-renders each time
the mouse moves, since the state is updated inside the nested hook.

> Hiding stateful logic within hooks doesn't remove their performance impact. The
> solution isn’t hiding complexity but smartly managing and isolating the state.

### How to Solve This

To avoid such issues, encapsulate state logic in smaller components:

```jsx
const Tooltip = () => {
  const {
    visible,
    show,
    hide
  } = useTooltipToggle();

  return (
    <>
      <button onMouseEnter={show} onMouseLeave={hide}>Hover me!</button>
      {visible && <Tooltip text="Hello, Tooltip!" />}
    </>
  );
};
```

This ensures that the minimal required area re-renders, preventing unnecessary updates across the entire app.

> In this solution, the `Tooltip` logic moved down from `App` to the own component. I described this approach in
> [this article](/blog/react-rerender#moving-state-down).

### Key Takeaway

The key lesson: carefully handle state encapsulation within custom hooks. Keep state management local and focused to
optimize your React application's performance and responsiveness.

> P.S Memoization and other performance optimizations will be covered in future posts. Meanwhile, you can read about [Elements, Children as Props, and Re-Renders](/blog/react-elements-children).


Learn about performance risks in React custom hooks, how they cause unexpected re-renders, and strategies to manage state efficiently.

Understanding the Hidden Pitfalls of Custom Hooks in React


<Image alt="React Re-Renders article cover illustration" src="react-rerender.png" priority={true} />

Hi, react [Andy](https://en.wiktionary.org/wiki/react_Andy)!

I’ve used React for over six years. I’ve noticed that even skilled programmers often struggle to grasp how React
operates behind the scenes. This can lead to inefficiencies. It affects code quality, speed, and user experience.

The documentation is great for starting with React. Many [books](https://www.roadtoreact.com/), courses, and blogs focus
on beginners. But what comes next? How can you dive deeper and really understand how it works? If you’ve been writing
React for a while, basic or
even intermediate courses may not be enough. Sadly, resources for advanced learning are limited.

That’s why I’m launching a [series of articles](/blog/category/advanced-react) to fill this knowledge gap.

## Intro to re-renders

Understanding re-renders in React is crucial for performance. You need to understand what triggers them. Know how they
move through the app. Learn what happens during a re-render and why it matters.

<Image alt="Meme about React re-renders" src="react-meme.png" />

## The problem

Imagine you’re an intern at a FAANG company. Your first task is to create a new React component. You’re asked to add a
simple `button` that opens a `modal dialog` at the top of the app.

```jsx
const App = () => {
  // Some code here
  return <div className="layout">
    {/* The button should go somewhere here */}
    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuff />
  </div>;
};
```

Then you implement it. The task seems trivial. We've all done it hundreds of times:

```jsx
const App = () => {
  // Add state  
  const [isOpen, setIsOpen] = useState(false);

  // Everything that is returned here will be re-rendered when the state is updated
  return <div>
    {/* Add the button */}
    <Button onClick={() => setIsOpen(true)}>
      Open dialog
    </Button>

    {/* Add the dialog */}
    {isOpen && <ModalDialog onClose={() => setIsOpen(false)} />}

    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuff />
  </div>;
};
```

You add [state](https://react.dev/learn/state-a-components-memory) to track if the dialog is open or closed. You include
a button to change the state and render the dialog
based on this state.

When you run the app, there’s a noticeable delay ⏰, **almost a second** — before the dialog appears.

Experienced React developers might quickly suggest.

> "You’re re-rendering the whole app. Just wrap everything in [React.memo](https://react.dev/reference/react/memo) and
> use [useCallback](https://react.dev/reference/react/useCallback) to avoid unnecessary renders."

This advice has its place, but it’s wise to pause before jumping in. In this case, memoization isn’t needed and could
hurt performance.

First, let’s take a closer look at what exactly is happening and why this delay occurs.

<Image alt="Diagram showing React component tree re-rendering when state updates" src="rerender.png" />

When we click the button, we trigger the `setIsOpen` setter function, which updates the `isOpen` state from `false` to
`true`. As a result, the `App` component that holds this state re-renders itself.

After the state updates and the `App` component re-renders, React must pass the new data to other dependent components.
It automatically re-renders all components that the first component shows. It keeps going down the tree until it reaches
the end.

If you visualize a typical React app as a tree structure, you will find that everything beneath the point where the
state update was initiated will be re-rendered.

> Re-rendering is crucial to understand in React.

The key point to remember is that React never re-renders components "up" the render tree. If a state update occurs in
the middle of the component tree, only the components "down" the tree will be re-rendered.

<Image alt="Diagram showing re-renders propagating down the component tree from state update" src="rerender-state.png" />

When a component is wrapped in `React.memo`, `React` will interrupt its default re-rendering process and first evaluate
whether the `props` have changed. If there are no changes to the `props`, re-renders will be halted. However, if even a
single `prop` is modified, the re-rendering will proceed as usual.

It's important to note that effectively preventing re-renders through memoization is a nuanced topic with various
considerations. For a deeper understanding, it is advisable to explore these concepts further in new articles. (Coming soon... or read about [Elements, Children as Props, and Re-Renders](/blog/react-elements-children))

<Image alt="Diagram showing how React.memo prevents unnecessary re-renders" src="react-memo.png" />


Wrapping components with `React.memo` can indeed help prevent unnecessary re-renders in certain scenarios. However, it's
important to note that using `React.memo` comes with its own set of complexities and caveats, which will be discussed in
future articles. A more effective approach is to isolate the components that rely on specific state and encapsulate both
the state and those components into a smaller, dedicated component. This can lead to improved performance and a clearer
component structure.

## Moving state down

Let's move our logic in separated component.

```jsx
const ButtonWithModalDialog = () => {
  const [isOpen, setIsOpen] = useState(false);

  return <>
    <Button onClick={() => setIsOpen(true)}>
      Open dialog
    </Button>

    {isOpen && <ModalDialog onClose={() => setIsOpen(false)} />}
  </>;
};
```

And then render this new component in the `App`:

```jsx
const App = () => {
  return <div>
    // Our new component
    <ButtonWithModalDialog />

    <VerySlowComponent />
    <AnotherComponent />
    <OtherStuffComponent />
  </div>;
};
```

<Image alt="Diagram showing performance improvement after moving state to a separate component" src="rerender-performance-fix.png" />

Consequently, the modal dialog appears immediately. We resolved a significant performance issue using a straightforward
composition technique!


Dive into the mechanics of React re-renders — learn what causes them, how they impact performance, and how to manage them effectively.

Understanding React Re-Renders: What Triggers Them and Why They Matter

Master advanced React patterns: render props, compound components, custom hooks, and performance optimization techniques.

Advanced React3 articles

Articles

Elements & Children Props

Custom Hooks Pitfalls

React Re-Renders