Add information about ref handling in strict mode #6777
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. 🤖
|
| Page | Size (compressed) |
|---|---|
global |
104.24 KB (🟡 +89 B) |
Details
The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!
Five Pages Changed Size
The following pages changed size from the code in this PR compared to its base branch:
| Page | Size (compressed) | First Load |
|---|---|---|
/404 |
82.3 KB (🟡 +1.2 KB) |
186.54 KB |
/500 |
82.29 KB (🟡 +1.2 KB) |
186.53 KB |
/[[...markdownPath]] |
84.14 KB (🟡 +1.2 KB) |
188.38 KB |
/errors |
82.51 KB (🟡 +1.2 KB) |
186.74 KB |
/errors/[errorCode] |
82.48 KB (🟡 +1.2 KB) |
186.72 KB |
Details
Only 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 next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.
Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis
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.
|
|
||
| For [`ref` callbacks](/reference/react-dom/components/common#ref-callback), React will call the callback function with the DOM node as its argument. It will then call the callback's [cleanup function](reference/react-dom/components/common#returns) before calling the `ref` callback function again with the DOM node as its argument. | ||
|
|
||
| Similarly, React will detach DOM refs that were created via `useRef` by setting `ref.current` to `null` before setting it back to the DOM node. |
There was a problem hiding this comment.
useRef is probably more common than callback refs. Maybe just flip it to put this statement before the line above?
There was a problem hiding this comment.
i was debating doing this, but that's a good justification - thanks
| @@ -825,7 +827,19 @@ Without Strict Mode, it was easy to miss that your Effect needed cleanup. By run | |||
| [Read more about implementing Effect cleanup.](/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development) | |||
|
|
|||
| --- | |||
| ### Fixing bugs found by detaching and re-attaching DOM refs in development {/*fixing-bugs-found-by-cleaning-up-and-re-attaching-dom-refs-in-development*/} | |||
There was a problem hiding this comment.
I think the <Canary> component should start above this line since this category is only applicable in canary
There was a problem hiding this comment.
it seems like the header doesn't show up properly in the outline if i do that. maybe can fix that though
There was a problem hiding this comment.
Not a big deal if it messes up the formatting
There was a problem hiding this comment.
We should just say "refs" instead of "DOM refs". Double invoking works for all of them now: https://ccp74m.csb.app/
There was a problem hiding this comment.
we don't currently have terminology to differentiate clearly between refs as a general store for data (eg: a ref object created via useRef which points to some arbitrary value) versus refs as passed to an element. we currently seem to conceptualize this in the docs as being centered around interation with DOM elements (example) even though this doesn't clearly encompass the kinds of refs like your example shows. open to suggestions though – perhaps i'm overthinking this and just saying "refs" is fine.
There was a problem hiding this comment.
what about "detaching and re-attachin refs to components" to make it clear we're not talking about refs as datastores like useRef?
There was a problem hiding this comment.
i think that makes sense. i wasn't sure if "components" would be inclusive of DOM elements, but it looks like elsewhere in the reference docs we refer to these as "common components", so i think that works.
noahlemen
changed the title
noahlemen
force-pushed
the
strictmode-dom-refs
branch
from
b46caa8
to
48573b0
Compare
|
See also this issue that I opened a while back: #6123. In it, I proposed that we update the React docs to discourage developers from relying on Given that React 19 is now fixing refs so they run twice in strict mode (facebook/react#24670), I think it's worth flagging the "useRef to run useEffect once on mount" hack in the docs as an anti-pattern. Our code base adopted this widespread pattern back when we were upgrading to React 18, and now it seems like we've only delayed the inevitable. For example, search up "React 18 strict mode run useEffect once" or something along those lines, and nearly every answer that comes up suggests using |
|
@AleksandrHovhannisyan note that this only impacts element refs like DOM nodes and refs with I added docs for the pattern you suggested here: #6846 |
rickhanlonii
force-pushed
the
strictmode-dom-refs
branch
from
a5bbeba
to
9f412ca
Compare
rickhanlonii
force-pushed
the
strictmode-dom-refs
branch
from
f930da4
to
841a1ad
Compare
No description provided.