ReactJS Tips & Tricks: Avoid Nested Render Functions

A common thing I noticed in a lot of projects I worked on is the Nested Render Functions approach to render UI elements.

Let's dive into this approach and how to change in a better way.

What are Nested Render Functions?

Basically, it is when you declare a part of UI render in a function inside of a component, such as:

const Component = () => {
  function renderSection() {
    return <section>This is my section.</section>
  }

  return (
    <div>
      {renderSection()}
      ...
    </div>
  )
}

Since components are just functions, it is the same as declaring new components inside the current Component.

Extracting to a New Component

It is much better to extract to a new component, it will help you to create unit tests more easily and isolated to the component.

Let's re-create the example I mentioned before, like the following:

const Section = () => <section>This is my section.</section>

const Component = () => (
  <div>
    <Section />
    ...
  </div>
)

Instead of using closures, now you have a pure function for Section component, that's more readable and easy to give their props.

Wrapping Up

With this approach, you will create more deterministic components taking the benefit of React pure component.

It will help you to test the component and create isolated behaviour for every component.

Comments

[Sushant Garudkar]

Loved the post!!

[Helder Burato Berto]

I'm glad you liked it.

[eBitzu]

I think you should explain why it's not ok, starting with the unnecessary creation on each re-render, which in fact triggers the returnComponent to re-render every time the Component re-renders.

[Delcio Polanco]

Do you recommend do this also for handlers events functions ?

[Helder Burato Berto]

If you are talking about cases like this:

const Component = ({ onClick }) => {
  const handleClick = () => {
    onClick();
  }

  return <button onClick={handleClick}>Click me!</button>;
}

IMO, it's totally unnecessary the handleClick if it is just to trigger the onClick, but if you have some logic to to before trigger the onClick, it make sense to stay there.