[Flight] Add DebugInfo for Bundler Chunks #34226
Conversation
github-actions
bot
added
the
React Core Team
sebmarkbage
force-pushed
the
devtoolsbundlerchunks
branch
from
cff1575 to
a0b5498
Compare
| } | ||
|
|
||
| // We cache ReactIOInfo across requests so that inner refreshes can dedupe with outer. | ||
| const chunkIOInfoCache: Map<string, ReactIOInfo> = __DEV__ |
There was a problem hiding this comment.
Can we clean this up at some point? You probably end up reloading the page at some point during a dev session but it's still a potential memory leak, right?
I guess that's also another reason why we don't collect these on the Server? Dev servers are usually longer alive than pages.
There was a problem hiding this comment.
Unless we get an event from webpack when a chunk has been invalidated and is no longer useful such as when it restarts, we can't really clean it up by the key.
We could potentially have a finalizer on the ReactIOInfo itself since this is not really about caching work but caching the referential identity and if there isn't any other objects retaining the old object then we don't really need it in the cache.
packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpackBrowser.js
Show resolved
Hide resolved
If they happened on the client, they they didn't block the Server Component.
| } else if ( | ||
| candidateInfo.awaited && | ||
| // Skip awaits on client resources since they didn't block the server component. | ||
| candidateInfo.awaited.env != null |
There was a problem hiding this comment.
I added these checks to only log awaits on something with an environment in the Server Components track.
That's because we now have debug info that originates on the client so they don't block the Server Component from completing on the server. They may still block the (Client) Component track but shouldn't be included in the Server Components track.
Currently these aren't included anyway since there's no start time on the lazy nodes but with some other changes this could change.
These are already not included in the Server Requests track since that's just logged when IO rows are resolved.
4 participants
This adds a "suspended by" row for each chunk that is referenced from a client reference. So when you select a client component, you can see what bundles will block that client component when loading on the client.
This is only done in the browser build since if we added it on the server, it would show up as a blocking resource and while it's possible we expect that a typical server request won't block on loading JS.
Currently this is only included if it ends up wrapped in a lazy like in the typical type position of a Client Component, but there's a general issue that maybe hard references need to transfer their debug info to the parent which can transfer it to the Fiber.