Unfork Lazy Component Branches#13902
Merged
acdlite merged 7 commits intofacebook:masterfrom Oct 20, 2018
Merged
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.
sebmarkbage
force-pushed
the
refactorpurelazy
branch
from
b577b26 to
6a70389
Compare
acdlite
reviewed
Oct 20, 2018
| mode: TypeOfMode, | ||
| expirationTime: ExpirationTime, | ||
| ): Fiber { | ||
| const fiber = createFiberFromElementWithoutDebugInfo( |
Collaborator
There was a problem hiding this comment.
Why the two functions? Doesn't look like this is called anywhere else
Contributor
Author
There was a problem hiding this comment.
So that I can do early returns in the other one. Compiler can restructure and get rid of it in prod.
acdlite
reviewed
Oct 20, 2018
| child = updateFunctionComponent( | ||
| null, | ||
| workInProgress, | ||
| Component, |
Collaborator
There was a problem hiding this comment.
Should we get rid of this argument now?
acdlite
approved these changes
Oct 20, 2018
| let child; | ||
| switch (resolvedTag) { | ||
| case FunctionComponent: { | ||
| child = updateFunctionComponent( |
Collaborator
There was a problem hiding this comment.
These can be early returns
Collaborator
|
Merging so I can sync to www |
acdlite
reviewed
Oct 20, 2018
| } | ||
| case ForwardRef: | ||
| case ForwardRefLazy: | ||
| break; |
Collaborator
There was a problem hiding this comment.
Oops, shouldn't have deleted the break, because now it falls through to SuspenseComponent. I'll revert.
linjiajian999
pushed a commit
to linjiajian999/react
that referenced
this pull request
Oct 22, 2018
* 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
jetoneza
pushed a commit
to jetoneza/react
that referenced
this pull request
Jan 23, 2019
* 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
NMinhNguyen
referenced
this pull request
in enzymejs/react-shallow-renderer
Jan 29, 2020
* 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
bvaughn
pushed a commit
to bvaughn/react
that referenced
this pull request
Dec 1, 2020
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.
bvaughn
pushed a commit
to bvaughn/react
that referenced
this pull request
Dec 1, 2020
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.
bvaughn
pushed a commit
to bvaughn/react
that referenced
this pull request
Dec 1, 2020
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.
bvaughn
pushed a commit
that referenced
this pull request
Dec 1, 2020
* 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
bvaughn
pushed a commit
to bvaughn/react
that referenced
this pull request
Dec 1, 2020
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.
bvaughn
pushed a commit
to bvaughn/react
that referenced
this pull request
Dec 4, 2020
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.
koto
pushed a commit
to koto/react
that referenced
this pull request
Jun 15, 2021
* 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.