You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would've expected that for both roots we get the nearest Suspense boundary that can commit after LazyComponent resolved. Or at least the fiber that "unsuspended" (not sure if this is the right terminology). The corresponding hostroot wouldn't help me much but I'm not that concerned with legacy roots in this instance.
Right now the information isn't all that helpful. I noticed this especially for a larger apps with multiple suspense boundaries and partial hydration.
I profiled the same codesandbox in the scheduling profiler but also couldn't extract any useful information with regards to why the second commit happened.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
React version: 18.2.0
Devtools version: 4.23.0-e28a0db22
Since #21171 React Devtools shows which fiber scheduled an update.
In the case of
where
LazyComponent
is someReact.lazy(() => {})
component we usually create two commits:LazyComponent
suspendsLazyComponents
resolvesIn legacy roots for the revealing commit Devtools displays the hostroot as the updater: https://github.com/facebook/react/pull/22602/files#diff-3582df0bd6a071e1986363b080d3012a9c492b8be7dd4e67f39d72078422d316R1368-R1376.
For new roots we get "unknown" for the second commit (i.e. no updates): https://github.com/facebook/react/pull/22602/files#diff-3582df0bd6a071e1986363b080d3012a9c492b8be7dd4e67f39d72078422d316R1267.
Codesandbox for full repro: https://codesandbox.io/p/sandbox/18-2-updaters-when-lazy-component-resolves-ff5x6h
I would've expected that for both roots we get the nearest Suspense boundary that can commit after
LazyComponent
resolved. Or at least the fiber that "unsuspended" (not sure if this is the right terminology). The corresponding hostroot wouldn't help me much but I'm not that concerned with legacy roots in this instance.Right now the information isn't all that helpful. I noticed this especially for a larger apps with multiple suspense boundaries and partial hydration.
I profiled the same codesandbox in the scheduling profiler but also couldn't extract any useful information with regards to why the second commit happened.
The text was updated successfully, but these errors were encountered: