SlotFill: add dependencies to updateFill effect#77907
Merged
Merged
Conversation
jsnajdr
added
[Type] Code Quality
|
Size Change: +2 B (0%) Total Size: 7.87 MB 📦 View Changed
ℹ️ View Unchanged
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Flaky tests detected in c7c3743. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25310382847
|
Mamaduka
approved these changes
May 4, 2026
Member
Mamaduka
left a comment
Mamaduka
left a comment
There was a problem hiding this comment.
Looks good to me ✅
Adding deps technically won't change the number of times this effect is called.
aduth
reviewed
May 4, 2026
| registry.updateFill( name, { | ||
| instance: instanceRef.current, | ||
| children: childrenRef.current, | ||
| children, |
Member
There was a problem hiding this comment.
I wonder how this might impact the separate useLayoutEffect above. Do we need both of them? Why does the other use childrenRef and this one children ? (Do we need childrenRef at all?)
Member
Author
There was a problem hiding this comment.
These are three effects that collaborate together:
- we need to call
registerFillon mount andunregisterFillon unmount. TheregisterFillcall needs achildrenarg, but we don't want to re-register the fill on everychildrenchange. That's why the value needs to be passed into the effect as a ref. That's also the only reason whychildrenRefis needed. - we need to call
updateFillon every re-render, when newchildrenvalue is passed. This effect wants to run on everychildrenchange, so thechildrendependency is warranted. TheupdateFillmethod does its own internal check whetherprevChildren !== nextChildren, so even the effect without any dependencies, running on every render, was OK. It just raises eyebrows (both human and linter's).
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
3 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.
Follow-up to #68056 which I promised in the review (#68056 (comment)) and now @obenland reminded me about it 🙂
Adds dependencies to layout effect that calls
updateFillwith updatedchildren.I don't think anything will really change after this PR.
childrenare typically different on every render (a new element created from JSX markup), so the effect will be triggered on every render. And it will store the latestchildrenand trigger a re-render of theSlot. Now we're just adding thechildrenexplicitly as dependency and avoid suspicious effect without dependencies.I'm also updating the
childrenRef.currentexpression to simplychildren. They are guaranteed to be the same, because an earllier layout effects callschildrenRef.current = children. And if I didn't do it, eslint would complain about a dependency that is not really used by the effect callback.