reactjs / reactjs/react.dev

[Suggestion]: Documentation does not make mention of the difference between `props.children` and directly rendering children as it relates to rendering behaviour.

Open
#8,007 1 comment 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: documentation
Dominant language
JavaScript
Stars
11.8k
Forks
7.9k
Avg merge
1d 11h
Merged PRs (30d)
11

Description

Summary

Here I have an example of two ways we can create functionally identical components.

export function ChildrenStyleOne() {
    const [value, setValue] = useState('');
    return <div id="foo">
        <SomeThing />
    </div>
}

export function ChildrenStyleTwo(props: React.PropsWithChildren) {
    const [value, setValue] = useState('');
    return <div id="bar">
        {props.children}
    </div>
}

However, there is an important different in how these components behave as far as rendering behaviour goes.

In the first style, every render of ChildrenStyleOne (eg. say because state is changing), will also cause a render of SomeThing.

In the second style, additional renders of ChildrenStyleTwo will not cause renders of the {props.children}.

This is a useful distinction to be aware of - using the props.children/slots approach is a simple mechanism to avoid full branch renders.

I've observed people commonly believing that 'every time a context provider's state changes, everything below it will render' - and I believe this misconception arrises from not being aware of this difference in rendering behaviour.

Page

https://react.dev/learn/understanding-your-ui-as-a-tree

Details

The docs above actually serve to reinforce the conflation of directly rendered children,and props.children.

For example the example code includes this node:

      <InspirationGenerator>
        <Copyright year={2004} />
      </InspirationGenerator>

and the render tree diagram looks like this:

Image

We can see that FancyText here is a directly rendered child, while Copyright is a props.children child.

The render tree described in the docs makes no distinction between the two.

I imagine this is likely a deliberate decision on the the part of the React maintainers - simplifying the conceptual model. If that's the case, is there a blog post or something that talks about what the strategy is?

The docs perhaps could do with a deep dive note that makes mention of this distinction or links to a more comprehensive optimisation section elsewhere.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the “Understanding your UI as a tree” page and inspect the InspirationGenerator example, especially the directly rendered FancyText and the props.children-based Copyright child. Determine whether the documentation should explain their rendering distinction or link to a deeper optimization resource. Done means the page accurately addresses the distinction or clearly explains the intended simplified model.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.