-
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
Unfork Lazy Component Branches #13902
Conversation
ReactDOM: size: -0.3%, gzip: -0.1% Details of bundled changes.Comparing: 7268d97...b2ee274 react-dom
react-art
react-test-renderer
react-reconciler
react-native-renderer
scheduler
Generated by 🚫 dangerJS |
This will be used to store the wrapped type of an element. E.g. pure and lazy. The existing type field will be used for the unwrapped type within them.
Instead, we check if the elementType and type are equal to test if we need to resolve props. This is slightly slower in the normal case but will yield less code and branching.
This way we don't have to check the type in a hacky way in the indeterminate path. Also, lets us deal with lazy that resolves to indeterminate and such.
b577b26
to
6a70389
Compare
mode: TypeOfMode, | ||
expirationTime: ExpirationTime, | ||
): Fiber { | ||
const fiber = createFiberFromElementWithoutDebugInfo( |
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 the two functions? Doesn't look like this is called anywhere else
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.
So that I can do early returns in the other one. Compiler can restructure and get rid of it in prod.
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 believe you
child = updateFunctionComponent( | ||
null, | ||
workInProgress, | ||
Component, |
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 we get rid of this argument now?
let child; | ||
switch (resolvedTag) { | ||
case FunctionComponent: { | ||
child = updateFunctionComponent( |
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.
These can be early returns
Merging so I can sync to www |
@@ -694,8 +684,6 @@ function completeWork( | |||
break; | |||
} | |||
case ForwardRef: | |||
case ForwardRefLazy: | |||
break; |
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.
Oops, shouldn't have deleted the break, because now it falls through to SuspenseComponent
. I'll revert.
* Introduce elementType field This will be used to store the wrapped type of an element. E.g. pure and lazy. The existing type field will be used for the unwrapped type within them. * Store the unwrapped type on the type field of lazy components * Use the raw tags for lazy components Instead, we check if the elementType and type are equal to test if we need to resolve props. This is slightly slower in the normal case but will yield less code and branching. * Clean up lazy branches * Collapse work tag numbering * Split IndeterminateComponent out from Lazy This way we don't have to check the type in a hacky way in the indeterminate path. Also, lets us deal with lazy that resolves to indeterminate and such. * Missing clean up in rebase
* Introduce elementType field This will be used to store the wrapped type of an element. E.g. pure and lazy. The existing type field will be used for the unwrapped type within them. * Store the unwrapped type on the type field of lazy components * Use the raw tags for lazy components Instead, we check if the elementType and type are equal to test if we need to resolve props. This is slightly slower in the normal case but will yield less code and branching. * Clean up lazy branches * Collapse work tag numbering * Split IndeterminateComponent out from Lazy This way we don't have to check the type in a hacky way in the indeterminate path. Also, lets us deal with lazy that resolves to indeterminate and such. * Missing clean up in rebase
* Introduce elementType field This will be used to store the wrapped type of an element. E.g. pure and lazy. The existing type field will be used for the unwrapped type within them. * Store the unwrapped type on the type field of lazy components * Use the raw tags for lazy components Instead, we check if the elementType and type are equal to test if we need to resolve props. This is slightly slower in the normal case but will yield less code and branching. * Clean up lazy branches * Collapse work tag numbering * Split IndeterminateComponent out from Lazy This way we don't have to check the type in a hacky way in the indeterminate path. Also, lets us deal with lazy that resolves to indeterminate and such. * Missing clean up in rebase
Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches.
Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches.
Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches.
* Fixed invalid DevTools work tags Work tags changed recently (PR #13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches. * Removed FundamentalComponent from DevTools tag defs
Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches.
Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches.
* Fixed invalid DevTools work tags Work tags changed recently (PR facebook#13902) but we didn't bump React versions. This meant that DevTools has valid work tags only for master (and FB www sync) but invalid work tags for the latest open source releases. To fix this, I incremneted React's version in Git (without an actual release) and added a new fork to the work tags detection branch. This commit also adds tags for the experimental Scope and Fundamental APIs to DevTools so component names will at least display correctly. Technically these new APIs were first introduced to experimental builds ~16.9 but I didn't add a new branch to the work tags fork because I don't they're used commonly. I've just added them to the 17+ branches. * Removed FundamentalComponent from DevTools tag defs
By adding an extra field for reconciliation purposes we can avoid the Lazy special cases. Normally it wouldn't be worth it but we can start using this technique for other things like pure.