-
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big deal if it messes up the formatting
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't currently have terminology to differentiate clearly between ref
s as a general store for data (eg: a ref
object created via useRef
which points to some arbitrary value) versus ref
s 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 |
a5bbeba
to
9f412ca
Compare
f930da4
to
841a1ad
Compare
* Convert "Canary" callouts to "React 19 beta" (#6811) * Convert "Canary" callouts to "React 19 beta" * Starting in * Bump version string * Bump deploy * Bump deploy * Bump deploy * [19] Remove <NextMajor> callouts (#6844) * Remove <NextMajor> callouts * rm if(node) * Delete removed APIs from 19 docs (#6845) * Add information about ref handling in strict mode (#6777) * Add information about DOM ref handling in strict mode * switch order of ref object / ref callback in strictmode doc * use 'refs to components' terminology instead of 'DOM refs' * update references to canary/r19 * Expand usage example and remove badges --------- Co-authored-by: Rick Hanlon <[email protected]> * [19] s/"Server Action"/"Server Function" (#7180) * [19] s/Server Action/Server Function * Revert /blog and change redirect * Add note * Tweak note * [v19] Update sandboxes to 19 RC (#7196) * Update transition docs for React 19 (#6837) * Add async transitions to React 19 docs * Updates from feedback * tweaks * grammar * Add startTranstion API * Apply suggestions from code review Co-authored-by: Noah Lemen <[email protected]> * Updated * capitalization * grammar --------- Co-authored-by: Noah Lemen <[email protected]> * [19] Add docs for prerender APIs (#7320) * Add prerender APIs * fix code blocks --------- Co-authored-by: Noah Lemen <[email protected]>
No description provided.