Split Update flag into a mutation and effect flag #27533
Conversation
The `Update` flag was overloaded to mean that there's "work to do during the commit phase". On the one side that was updates to host components. On the other side that meant running effects. The flag was also used in persistent mode to trigger cloning the immutable view hierarchy to perform the updates. When the flag was only used to indicate calling effects, this meant needlessly cloning the subtree. Here we *start* splitting up the flag into 2. In the transition phase we set both flags in some places, but most likey every location should only set or check one of the flags.
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 67cc9ba...fc3ac3a Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show |
| })); | ||
|
|
||
| const ComponentWithEffect = () => { | ||
| // Same thing happens with `ref` and `useImperativeHandle` |
There was a problem hiding this comment.
Worth testing that ref / useImperativeHandle now pass this test too?
There was a problem hiding this comment.
I think a better overall approach would be to add a flag that represents something that has been cloned. Call it Cloned or something.
It would only be set in persistent mode, not mutation mode, and it would accompany any call to cloneInstance, cloneText, et al.
Then you can update this function to check for Cloned instead of MutationMask:
react/packages/react-reconciler/src/ReactFiberCompleteWork.js
Lines 204 to 205 in 9abf6fa
I think this would be simpler because it's less likely the meanings of the flags will get overloaded again.
|
@acdlite Our thought for further splitting of this flag was that we could potentially safe some traversal down if only host components are updated, but other update effects aren't in place. Is that assumption wrong and we basically always have the (non-clone) effect set if there would be a "cloned" flag set? |
|
Superseded by #27647 |
The
Updateflag was overloaded to mean that there's "work to do during the commit phase". On the one side that was updates to host components. On the other side that meant running effects.The flag was also used in persistent mode to trigger cloning the immutable view hierarchy to perform the updates. When the flag was only used to indicate calling effects, this meant needlessly cloning the subtree.
Here we start splitting up the flag into 2. In the transition phase we set both flags in some places, but most likey every location should only set or check one of the flags.