Skip to content
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

Merged
merged 5 commits into from
Dec 12, 2017

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Dec 12, 2017

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.

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.
@acdlite acdlite force-pushed the use-elements-for-call-and-return branch from d0bae7a to 7aa0d19 Compare December 12, 2017 04:45
@@ -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(
Copy link
Collaborator

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...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Collaborator

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(
Copy link
Collaborator

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?

function getComponentName(fiber: Fiber): string | null {
const {type} = fiber;
if (type === REACT_CALL_TYPE) {
return '<ReactCall>';
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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') {
Copy link
Collaborator

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.
return type.displayName || type.name;
switch (type) {
case REACT_FRAGMENT_TYPE:
return '<ReactFragment>';
Copy link
Collaborator

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.

@acdlite acdlite merged commit b77b123 into facebook:master Dec 12, 2017
yenshih pushed a commit to yenshih/react that referenced this pull request Jan 6, 2018
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants