[Flight] Resolve deduped references when chunks are blocked on each other #32316
Conversation
github-actions
bot
added
the
React Core Team
unstubbable
changed the title
unstubbable
force-pushed
the
client-component-props-deduping
branch
from
414c443 to
ecb5a8a
Compare
packages/react-server-dom-webpack/src/__tests__/ReactFlightDOMBrowser-test.js
Show resolved
Hide resolved
| @@ -163,6 +163,7 @@ type BlockedChunk<T> = { | |||
| status: 'blocked', | |||
| value: null | Array<(T) => mixed>, | |||
| reason: null | Array<(mixed) => mixed>, | |||
| intermediaryValue?: mixed, | |||
| _response: Response, | |||
| _children: Array<SomeChunk<any>> | ProfilingResult, // Profiling-only | |||
There was a problem hiding this comment.
This is not "Profiling-only" anymore. I'm not sure this is actually reliable enough. It's more of a hack for profiling which is optional if it works or not.
There was a problem hiding this comment.
I think we can keep _children profiling-only. It was not necessary for this fix to remove the two guards around initializingChunk._children. I reverted that.
| @@ -3393,6 +3410,7 @@ function parseModel<T>(response: Response, json: UninitializedModel): T { | |||
| function createFromJSONCallback(response: Response) { | |||
| // $FlowFixMe[missing-this-annot] | |||
| return function (key: string, value: JSONValue) { | |||
| isParsingRootModel = key === ''; | |||
There was a problem hiding this comment.
We can't assume that an empty string key is the root since it may also be on nested objects. What's the implication of that?
There was a problem hiding this comment.
Hmm, we were already using the check here:
react/packages/react-client/src/ReactFlightClient.js
Lines 983 to 987 in 192555b
But I guess you're right, it could also be an explicit empty key in some object.
This PR includes a reduced test case of vercel/next.js#75726:
This is serialized into the following RSC payload which the Flight Client was not able to resolve, because two chunks are blocked on each other:
We can fix this by storing intermediary values (only elements for now) on the initializing chunk. When the
fulfilllistener inwaitForReferenceis called with a lazy element that has a blocked chunk, which is not the current chunk, we can peek into the intermediary value of the referenced chunk to resolve a reference for a different chunk that's still blocked.fixes vercel/next.js#72104