-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Call and Return components should use ReactElement #11834
Call and Return components should use ReactElement #11834
Conversation
ReactChildFiber contains lots of branches that do the same thing for different child types. We can unify them by having more child types be ReactElements. This requires that the `type` and `key` fields are sufficient to determine the identity of the child. The main benefit is decreased file size, especially as we add more component types, like context providers and consumers. This updates Call and Return components to use ReactElement. Portals are left alone for now because their identity includes the host instance.
d0bae7a
to
7aa0d19
Compare
@@ -621,11 +621,6 @@ class ReactDOMServerRenderer { | |||
'Portals are not currently supported by the server renderer. ' + | |||
'Render them conditionally so that they only appear on the client render.', | |||
); | |||
invariant( |
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.
This wasn’t a hot path...
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.
Updated
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.
Thanks, that part looks good
@@ -678,6 +673,12 @@ class ReactDOMServerRenderer { | |||
context: Object, | |||
parentNamespace: string, | |||
): string { | |||
invariant( |
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.
...but this is. Seems unfortunate to run this check every time.
(Also, if we do this I’d expect it to happen outside of renderDOM
which renders host components only.)
Since we already read .type
above when comparing to fragment maybe we should turn that branch into a switch?
packages/shared/getComponentName.js
Outdated
function getComponentName(fiber: Fiber): string | null { | ||
const {type} = fiber; | ||
if (type === REACT_CALL_TYPE) { | ||
return '<ReactCall>'; |
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.
Why didn’t Fragment need this?
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 guess because we don't have a test that covers them. I'll add one.
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.
Actually I guess the debug tool is supposed to skip over these
fiber.expirationTime = expirationTime; | ||
return fiber; | ||
default: { | ||
if (typeof type === 'function') { |
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 put these type checks first before the switch. Always make sure that the common path is first.
Don't think these were intentionally omitted from the blacklist of component types. I went ahead and updated getComponentName to include special types, even though I don't think they're used anywhere right now.
packages/shared/getComponentName.js
Outdated
return type.displayName || type.name; | ||
switch (type) { | ||
case REACT_FRAGMENT_TYPE: | ||
return '<ReactFragment>'; |
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.
Should this just be React.Fragment
? Same for others. Some our warnings put <
and />
around names.
* Call and Return components should use ReactElement ReactChildFiber contains lots of branches that do the same thing for different child types. We can unify them by having more child types be ReactElements. This requires that the `type` and `key` fields are sufficient to determine the identity of the child. The main benefit is decreased file size, especially as we add more component types, like context providers and consumers. This updates Call and Return components to use ReactElement. Portals are left alone for now because their identity includes the host instance. * Move server render invariant for call and return types * Sort ReactElement type checks by most likely * Performance timeline should skip over call components Don't think these were intentionally omitted from the blacklist of component types. I went ahead and updated getComponentName to include special types, even though I don't think they're used anywhere right now. * Remove surrounding brackets from internal display names
ReactChildFiber contains lots of branches that do the same thing for different child types. We can unify them by having more child types be ReactElements. This requires that the
type
andkey
fields are sufficient to determine the identity of the child.The main benefit is decreased file size, especially as we add more component types, like context providers and consumers.
This updates Call and Return components to use ReactElement. Portals are left alone for now because their identity includes the host instance.