ESLint: Fix a couple of React Compiler reassignment errors #66331
Conversation
This file contains 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
tyxla
added
[Type] Code Quality
|
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. |
Mamaduka
reviewed
Oct 22, 2024
| @@ -133,15 +135,15 @@ function ListViewBranch( props ) { | |||
| const blockCount = filteredBlocks.length; | |||
| // The appender means an extra row in List View, so add 1 to the row count. | |||
| const rowCount = showAppender ? blockCount + 1 : blockCount; | |||
| let nextPosition = listPosition; | |||
| nextPositionRef.current = listPosition; | |||
There was a problem hiding this comment.
This probably goes against the "don't read/write refs during render" rule, no?
There was a problem hiding this comment.
I thought it might, but it doesn't really trigger an error. And I think we can find similar usage across the repo already, so 🤷
There was a problem hiding this comment.
I wonder why exactly the compiler didn't like the nextPosition local variable. Maybe it's that it's incremented in a map callback and the compiler thinks that the callback is an event handler?
nextPosition is a legit local variable, assigned and used only during the render, and the value doesn't need to survive the render function. The ref is not really needed. Reading/writing it is safe because, well, it's used as a local variable.
|
Size Change: +12 B (0%) Total Size: 1.81 MB
ℹ️ View Unchanged
|
Mamaduka
reviewed
Oct 22, 2024
| removeNotice( noticeId ); | ||
| noticeId = `block-library/core/table-of-contents/redirection-prevented/${ instanceId }`; | ||
| removeNotice( noticeIdRef.current ); | ||
| noticeIdRef.current = `block-library/core/table-of-contents/redirection-prevented/${ instanceId }`; |
There was a problem hiding this comment.
Do we need reassignment here? The instanceId shouldn't change between rerenders; we can always use clientId if it does.
P.S. The Latest Posts block has similar logic.
gutenberg/packages/block-library/src/latest-posts/edit.js
Lines 159 to 169 in acf661c
There was a problem hiding this comment.
Does the version in Latest Posts really work? It seems to me that the noticeId is reset to undefined on each rerender of the block's Edit component. When you click and the showRedirectionPreventedNotice handler is called, the created notice id is saved, but on the next rerender it's lost again.
There was a problem hiding this comment.
Dispatching a notice won't rerender the Edit component, so the noticeId is retained. But yes, the value might get lost.
By the way, the following snippet has the same effect and displays only a single notice.
const showRedirectionPreventedNotice = ( event ) => {
event.preventDefault();
createWarningNotice( __( 'Links are disabled in the editor.' ), {
id: `block-library/core/latest-posts/redirection-prevented/${ instanceId }`,
type: 'snackbar',
} );
};There was a problem hiding this comment.
Dispatching a notice won't rerender, but if the component is rerendered for any other reason then the noticeId value will be lost. Adding the ref is a correct fix, and it should be applied also to the LatestPostsEdit component.
There was a problem hiding this comment.
I agree with @jsnajdr that the ref is the correct fix.
I'm happy to follow up with fixing that in LatestPostsEdit if we all agree on it.
There was a problem hiding this comment.
Followed up here for addressing in the Latest Posts block: #66404
There was a problem hiding this comment.
Even better follow-up here: #66409
This was referenced Oct 24, 2024
karthick-murugan
pushed a commit
to karthick-murugan/gutenberg
that referenced
this pull request
Nov 13, 2024
…#66331) Co-authored-by: tyxla <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: jsnajdr <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What?
Resolves a few straightforward violations of the React Compiler reassignment rule:
Why?
To resolve a few errors related to reassignment in #61788.
How?
We're using refs instead, to preserve the pre-existing non-reactive behavior.
Testing Instructions
Testing Instructions for Keyboard
Same
Screenshots or screencast
None