Skip to content

Commit 19ce90e

Browse files
committed
Assign resolved outlined props to element object (and not only tuple)
When an element is used multiple times as shown in facebook#30526, its props might be deduped. When resolving the reference to the deduped props, we were only updating the React element tuple, which at this point has already been parsed into a React element object, using `null` as placeholder props. Therefore, updating the element tuple doesn't help much, and we need to make sure that the element object's props are updated as well. This is a similar fix as facebook#28669, see the code lines above, and thus feels similarly hacky. Maybe there's a better way to fix this? @eps1lon was mentioning offline that solving [this TODO](https://github.com/facebook/react/blob/33e54fa252b9dbe7553ef42a2287c3dbbd4f035d/packages/react-client/src/ReactFlightClient.js#L1327) would probably fix it properly, since we wouldn't need to deal with stale tuples then. But that's a way heavier lift.
1 parent e26781e commit 19ce90e

File tree

1 file changed

+14
-0
lines changed

1 file changed

+14
-0
lines changed

packages/react-client/src/ReactFlightClient.js

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -902,6 +902,20 @@ function waitForReference<T>(
902902
handler.value = parentObject[key];
903903
}
904904

905+
// If the parent object is an unresolved React element tuple and its
906+
// outlined props have now been resolved, we also need to update the props
907+
// of the resolved element (i.e. handler.value).
908+
if (
909+
parentObject[0] === REACT_ELEMENT_TYPE &&
910+
key === '3' &&
911+
typeof handler.value === 'object' &&
912+
handler.value !== null &&
913+
handler.value.$$typeof === REACT_ELEMENT_TYPE &&
914+
handler.value.props === null
915+
) {
916+
handler.value.props = parentObject[key];
917+
}
918+
905919
handler.deps--;
906920

907921
if (handler.deps === 0) {

0 commit comments

Comments
 (0)