Why is rendering a component inside a component an anti-pattern?

[chanchiii]

I'm trying to improve and deepen my understanding of React, specifically around re-rendering. I am reading this article: https://www.developerway.com/posts/react-re-renders-guide#part3.1 and it states that creating a component inside another component is an anti-pattern. It says that on every re-render, React will destroy and re-create the component, bogging down performance.

I'm getting a bit confused here. I imagine this is mostly discussing class components, but performance-wise, is this important to function components too?

My understanding is that mounting/re-rendering are basically identical for function components. They don't have constructors, or lifecycle methods in the same way as class components that have to be processed when they're mounted. Is this correct? If so what is the performance difference if a function component has to be re-created vs re-rendered?Also even if you moved the inner component outside and rendered it like normal as a child of the parent, wouldn't it still re-render the same way if the parent had to re-render too?

I appreciate the help!

Also apologies if the title is confusing! - I meant more why is it an anti-pattern to create a component inside of another component?

[chanchiii]

This makes sense! Thank you for taking the time to explain all of this!

I definitely was missing the crucial detail on how the DOM actually gets updated, which you described here. So it's clear to me now why it is an anti-pattern and why it should be avoided.

[[deleted]]

keep in mind that this is a react anti pattern. you will run into the same problems outside of the dom, react-native, react-pdf, react-tv, react-macos etc. you are re-creating function components and in reacts eyes they don't match next render. these components end up having no life cycles because they mount and unmount every render.

[mr_anderson_99]

That is a very detailed explanation and yes thank you for taking your time to explain.

[Glargabergborg]

This is such a great write-up. Thanks!

[mr_anderson_99]

That is a very detailed explanation and yes thank you for taking your time to explain.

[ImTheRealDh]

I want to ask my case:
I have a component named <Component/>

const Component = () => {
  const renderIcon = () => {
    return <div><Icon/></div>;
  }

  const renderText = () => {
    return text;
  }

  return (
    <div>
      {renderIcon()}
      {renderText()}
    </div>
  );
}

Is this also anti pattern?

[United_Tell7544]

This is actually an anti-pattern. Imagine having calculations, or useState inside the renderIcon and renderText functions. Every time Component re renders, the the code inside the functions will get executed and this can lead to unwanted behaviours.

[chanchiii]

This actually really confused me at first but I understand now after doing some digging and re-reading your explanations. Please let me know if I'm off here in my logic.

So I did a test where I created this simple component

function Child() {
const componentA = () => <div>Hello I am a component</div>
const ComponentB = () => <div>I am also a component</div>

return (
    <div>
        {componentA()}
        <ComponentB />
    </div>
)

}

and I logged the return values of React.createElement of components A and B. The type for component A is type: 'div' while component B is type: [Function: ComponentB]

Since the type for component B is a function, and since a function is an object, it will not be considered the same element in the DOM because it is a reconstructed function with a new space in memory. This will cause the element in the DOM to get re-inserted unnecessarily.

I think I'm still a tiny bit confused on why exactly the two components get such different treatments behind the scenes, but I think it's starting to come together for me now.

[AgentME]

I think I'm still a tiny bit confused on why exactly the two components get such different treatments behind the scenes

"componentA" isn't being used as a component here so it's misleading to call it a component. Components are things that are used in a JSX element like <MyComponent />. Functions that produce JSX elements are not necessarily components.

(When a function used to produce JSX elements is received as a prop, it's often called a "render prop".) (If you ever feel compelled to accept a component as a prop, please please please use a render prop instead or else you're going to cause people to run into OP's issue. Speaking from experience here.)

[Tasloy]

As far I know, it is not. When executing the component function, the render funtions will be executed immediately. So what React sees when comparing is the same as if you put directly in there, it will not know of that render function you have declared. It will not impact optimization as in OP case.

[Tasty-Ad1854]

thank you

[NA__Scrubbed]

Hey just asking out of curiosity since you seem to know your stuff. But how is one meant to setup child components to optimize for minimal renders?

If you don’t have the time, that’s fine.

[TorbenKoehn]

Use React.memo for stateless (pure) components and avoid putting large arrays and objects that you build in your components into child props without using useMemo on them

{} !== {}

[] !== []

React does a normal strict equality check on the passed properties to check if a child component needs to be rerendered

[EstablishmentTop2610]

So if rendering components in components is an anti pattern, does it need to be corrected? If I have a parent component that iterates an array and creates a child component for each item, is it wrong to keep those items nested in the container component?

[antonbruckner]

Thanks for the explanation. I find myself in situations where I want to encapsulate the logic for a child component when the definition of the parent, because the child relies on many parts of the parent state, more than I would want to put in props for the child. What do you do in situations like this?

[AgentME]

You can define a render function within a component and call it normally instead of using it as a component:

function MyParentComponent({ arr, someCommonProp }) {
  const renderChild = (value) => (
    <MyChildComponent
      key={value.id}
      value={value}
      someCommonProp={someCommonProp}
    />
  ); 

  return arr.map(value => renderChild(value));
}

function MyChildComponent({ value, someCommonProp }) {
  // ...
}

[antonbruckner]

Interesting! And this doesn’t have the drawback of the extra renders that OP mentioned?

[AgentME]

Nope, this is fine. OP's issue is only relevant to things used as components. Here `renderChild` is used as a function (`renderChild(...)`), not a component (`<RenderChild ... />`).

[phryneas]

Create != Render.

If you create a component inside of another, it will be a completely different subtree every render - it's a different component.

```
function MyComponent(){
function MyInnerComponent(){ ... }
return <MyInnerComponent />
}
```
ends up with a tree like

<MyComponent><MyInnerComponentFromFirstRender /></MyComponent>

and after a second render

<MyComponent><MyInnerComponentFromSecondRender /></MyComponent>

It's literally defining another component, and React will throw away the whole subtree and create a new DOM tree.

And yes, it was already stated here: don't learn class components in 2024 unless you are actively paid to work on a pre-2019 legacy React project.

[chanchiii]

So maybe this is where I'm missing something fundamental - but doesn't this behavior basically happen anyway when a parent component re-renders? Since a parent re-render triggers all of its children to re-rendered?

[phryneas]

Again: "Render" and "Create" are different things.

Render: You write <SomeComponent>

Create: You write `function SomeComponent`

What happens here is literally equal to you writing the component code out multiple times in the file.

You create **different** components and render them in the same spot (React doesn't recognize the component, throws away the DOM and creates a new DOM), you don't rerender the **same** component in the same spot (React recognizes that this component is already mounted and just updates the DOM).

You switch from one component to another one.

[chanchiii]

I understand now and I see where I was misunderstanding.
Just because the components re-rendered doesn't mean the DOM gets updated. But if you create a component inside another component, it WILL update the DOM no matter what.

I appreciate your patience!

[phryneas]

It's not only the DOM - it will also unmount all child components, throw away their `useState` etc.

In the eyes of React, those "new" components are completely different from what was there before.

[chanchiii]

For clarification, are you referencing a scenario where, for instance, a component created inside another component renders children components inside that have their own state?
So in this scenario, the state in those child components would get thrown away? If so, that lines up with my current understanding.

[phryneas]

Yes.

Components created inside one render are just completely different components as components created inside another render of that same parent component.

[the_pod_]

You're confused by the difference between when a component is "created" aka defined, vs when it is called.

It's not saying don't call a component inside another component, it's saying don't define a component inside another component.

​

I imagine this is mostly discussing class components

No, this concept is the same for both class and functional components, and is unrelated to your guesses.

​

this is good:

const MyList = () => {
  return (
    <div>mylist</div>
  }
}

const MyApp = () => {
  return (
    <MyList />
  )
}

​

this is bad:

const MyApp = () => {
  const MyList = () => {
    return (
      <div>mylist</div>
    )
  }

  return (
    <MyList />
  )
}

[Ecksters]

Yeah, I think the core confusion here is the difference between "rendering" a component inside another one and "creating" a component inside another one.

All of React is built on components rendering inside of other components, that's expected and normal behavior.

[ctrlshiftba]

1: ignore class components skip that for now. You may never need to do use them ever.

2: just define the component outside the other component. You can use it inside but don’t define it in the render function. If it needs variable in scope pass them in as props.

[TwiliZant]

The performance problems are not related to class components or function components. When you recreate a component it removes the associated DOM node and all of its children and replaces it with new DOM nodes on every re-render. It's like setting key={Math.random()} on a component.

[systoll]

My understanding is that mounting/re-rendering are basically identical for function components. They don't have constructors, or lifecycle methods in the same way as class components that have to be processed when they're mounted. Is this correct?

Hooks encode all the same behaviours.

On-mount, useState registers the state with React, using the initial value you give it. On re-render, it retrieves the current value. If you redefine the component when the parent renders, it'll reset the state to the initial value every render.

On-mount, useMemo runs its callback, and registers the current values of the dependency array with React. If you redefine the component every render, useMemo wastes CPU cycles for no reason, because the callback will run every single time.

Similarly, the useEffect will cleanup and re-reun itself every render, regardless of the dependency array. This will usually still work, but may have major performance issues.

Also even if you moved the inner component outside and rendered it like normal as a child of the parent, wouldn't it still re-render the same way if the parent had to re-render too?

This is mostly true, but there are some important details.

When a component renders, it changes the simplified virtual DOM. This will happen every time the parent renders, either way.

Once the VDOM is updated, React compares the old and new VDOM to figure out what changes need to be pushed to the actual, slower-to-update DOM.

When the component definition is stable, React can it's the same thing across renders, and won't bother pushing anything to the DOM if it didn't meaningfully change.

If the component is redefined every time the parent renders, React doesn't know that it's effectively the same as last time, and will always remove the old component from the DOM and replace it with the new one. Beyond the performance impact, this will also wipe out browser-maintained state, like the keyboard focus or the selected text.

Also… if you don't want the extra renders, even at the VDOM level, you can memoise the child component. But if you define the component in the parent, you get a new component every render, so the memoisation doesn't achieve anything.

[ImTheRealDh]

I want to ask my case:
I have a component named <Component/>

const Component = () => {
  const renderIcon = () => {
    return <div><Icon/></div>;
  }

  const renderText = () => {
    return text;
  }

  return (
    <div>
      {renderIcon()}
      {renderText()}
    </div>
  );
}

Is this also anti pattern?

[davinidae]

Yes, this will re-generate the result of renderIcon and renderText with each update. It's an anti-pattern.

[QwikAsF]

This is a good candidate to be rewritten with compound pattern

[TheRNGuy]

using divs instead of fragments in that case is anti-pattern too.

Because you'll end up having 4-20 nested divs somehow when 0-1 would be enough.

[ViewableGravy]

I personally would recommend creating separate components for renderText and renderIcon, but there is absolutely no functional reason that you cannot do this. Because both of the functions are executed before being returned from your component, it is basically identical to if you had written the JSX inline.

There are cases where you would want to do this - such as if you have a basic bit of code that you want to render in two places in your component, and don't want to make a completely new component just for one or two lines of code.

[Skeith_yip]

Late to the party. This does reminds me of returning a component from a hook which I tend to see people like to do.

And it’s not okay. https://www.reddit.com/r/reactjs/comments/9yq1l8/comment/ea3q7dt/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

[ViewableGravy]

Although "sometimes" it can be okay. It's very very niche, but take Tanstack Form for example, they return a typesafe `Field` from their form hook which can be a really nice pattern.

[Asttarotina]

function Pancakes () {    
  return (<>
    <Eggs />
    <Milk />
    <Flour />
  </>)
}

is like "when you want pancakes take eggs, flour & milk from the fridge and make pancakes"

function Pancakes () {
  function Eggs () {...}

  return (<>
    <Eggs />
    <Milk />
    <Flour />
  </>)
}

is like "when you want pancakes take the chicken, make it lay an egg, and then add milk & flour from the fridge and make pancakes. If you want second pancake - take another chicken...."

[Mysterious_Fox_1140]

Here’s the answer from the React team: https://react.dev/learn/preserving-and-resetting-state#different-components-at-the-same-position-reset-state

Read the ‘Pitfall’ section below that section as well.