-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Describing Your UI > Your UI as a tree #6334
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Size changes📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 Three Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If Any third party scripts you have added directly to your app using the Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 10% or more, there will be a red status indicator applied, indicating that special attention should be given to this. |
From components, React creates a UI tree which React DOM uses to render the DOM | ||
</Diagram> | ||
|
||
React also uses tree structures to manage and model the relationship between components in a React app. These trees are useful tools to understand how data flows through a React app and how to optimize rendering and app size. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be nice to have a note that DOM is not the only thing you can render to e.g. mobile, desktop, VR, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mention this in the deep dive. I think it might make more sense there -- at this point, I think I'd like to keep the emphasis that "trees are useful data structures" and "React uses trees just like browsers, mobile platforms, etc". Rendering is not necessarily related to the concept of a React tree.
[comment]: <> (I'm not sure if we should have this, I think I'm trying to get the point across that render trees are platform-agnostic tool for understanding your React app) | ||
<DeepDive> | ||
|
||
#### Where are the HTML tags in the render tree? {/*where-are-the-html-elements-in-the-render-tree*/} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love this deep dive! Very clear and relevant explications
|
||
From the example app, we can construct the above render tree. Each node in the tree represents a component and the root node is the [root component](/learn/importing-and-exporting-components#the-root-component-file). In this case, the root component is `App` and it is the first component React renders. Each arrow in the tree points from a parent component to a child component. | ||
|
||
We often refer to the components near the root of the tree as "top-level components". They are ancestors and have a lot of descendent components. Components that have no children are referred to as "leaves". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this important to what you're trying to communicate here? I think this concept might be better introduced closer to where someone can see the term in use (e.g. you should move your state to the lowest level, or "leaves" of your components.) rather than a blanket statement that is likely to be forgotten.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention in bringing it up here is to mention it in the purpose of render trees -- or why they're useful.
I have this later on:
Although render trees may differ across render pases, these trees are generally helpful for identifying what the top-level components are in a React app. Top-level components affect the rendering performance of all the components beneath them and often contain the most complexity.
I could move this introduction of 'top-level components' and 'leaves' closer to this.
|
||
</DeepDive> | ||
|
||
A render tree represents a single render pass of a React application. With [conditional rendering](/learn/conditional-rendering), a parent component may render different children depending on the data passed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A render tree represents a single render pass of a React application
Is this, strictly speaking, true? Can't you have multiple render passes with the same tree due to state updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, a render tree is a representation of the components rendered in a single render pass. That wouldn't negate the fact that multiple renders may result in the same render tree. Just trying to point out that a React app may render different components depending on state/data. Let me know if my wording could make this clearer.
|
||
In this example, depending on what `greeting.type` is, we may render `<Title>` or `<Image>`. The render tree may be different for each render pass. | ||
|
||
Although render trees may differ across render pases, these trees are generally helpful for identifying what the top-level components are in a React app. Top-level components affect the rendering performance of all the components beneath them and often contain the most complexity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are you trying to communicate here? how is this important to a dev's understanding of React as a tree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, like why do we care about render trees? Especially in contrast to dependency trees. I'm trying to say that render trees are a useful model for understanding component relationships for debugging performance issues. I can try to highlight that a bit more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've expanded this a bit more to clarify
``` | ||
</Sandpack> | ||
|
||
<Diagram name="conditional_render_tree" height={300} width={522} alt="TODO."> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO
Maybe put the text below the diagram in alt text for now? e.g. With conditional rendering, across different renders, the render tree may render different components.
|
||
Trees are a relationship model between items and UI is often represented using tree structures. For example on browsers, the [DOM](https://developer.mozilla.org/docs/Web/API/Document_Object_Model/Introduction) represents HTML elements while the [CSSOM](https://developer.mozilla.org/docs/Web/API/CSS_Object_Model) does the same for CSS. Similar for mobile, platform views relate to one another in a tree format. There’s even an [Accessibility tree](https://developer.mozilla.org/docs/Glossary/Accessibility_tree)! | ||
|
||
<Diagram name="preserving_state_dom_tree" height={193} width={864} alt="Diagram with three sections arranged horizontally. In the first section, there are three rectangles stacked vertically, with labels 'Component A', 'Component B', and 'Component C'. Transitioning to the next pane is an arrow with the React logo on top labeled 'React'. The middle section contains a tree of components, with the root labeled 'A' and two children labeled 'B' and 'C'. The next section is again transitioned using an arrow with the React logo on top labeled 'React'. The third and final section is a wireframe of a browser, containing a tree of 8 nodes, which has only a subset highlighted (indicating the subtree from the middle section)."> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a little bit confusing to have this diagram here with 'Component A', 'Component B', and 'Component C' while the rest of the diagrams use a different set of components ('Greeting', 'Title', 'App', etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, this was a diagram that was moved over from another section of the learn docs. My thinking was that this intro here introduces the general concept of trees and not directly tied to the examples yet, so it's okay to be an abstract diagram.
|
||
Each node in a module dependency tree is a module and each branch represents an `import` statement in that module. | ||
|
||
If we take the previous Greeting app, we can build a module dependency tree, or dependency tree for short. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can build a module dependency tree, or dependency tree for short
Is a "dependency tree" distinct from a "module dependency tree" in other languages? this might be confusing to someone coming from another background if "dependency tree" has meaning outside of what you're describing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I personally don't think it'd be a source of confusion even for other languages as we're setting the context that we're using it as a shorthand for module dependency tree here. if you feel strongly, happy to change!
cd9d44f
to
d7927ea
Compare
This PR introduces a new section under "Describing your UI" to better introduce UI trees and module dependency trees which will be expanded upon in later sections.
It will also be useful for
use client
directive docs.Things to still do
Preview