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.

未關閉
#8,007 1 則留言 5 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

type: documentation
主要語言
JavaScript
星號
11.8k
分支
7.9k
平均合併
1 天 11 小時
30 天內合併 PR
11

描述

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.

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

從「Understanding your UI as a tree」頁面開始,檢視 InspirationGenerator 範例,特別是直接渲染的 FancyText 和基於 props.children 的 Copyright 子項。判斷文件是否應該解釋它們在渲染上的差異,或連結到更深入的最佳化資源。當頁面準確處理這項差異,或清楚解釋預期的簡化模型時,即視為完成。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
javascript, react
領域
documentation
Issue 類型
文件
難度
3/5
預估耗時
1-2 天
活躍度
停滯
描述清晰度
基本清楚
新手友好度
42/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。