Components: Fix block editor crash when multiple Autocompleters are placed in the same block #41770
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
chad1008
added
[Type] Bug
|
Size Change: +15 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
|
As per #41749 (comment), we plan on reverting #41382 before adding more tests and working on a more solid refactor for the |
|
Closing, as the regression this was meant to address has been reverted: #41820 |
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?
Proposed fix for #41709
Dependent on #41749
Why?
The
Autocompletecomponent was recently refactored to passexhaustive-deps, and some of the new dependencies have had unexpected side effects. Specifically for this PR, if you have multiple Autocompleters you want to use in a single block, the second one can trigger a loop that crashes the editor.How?
This crash appears to have been triggered by the combination of two new
useEffectdependencies:onChangeOptionsinautocomplete/autocompleter-ui.js: This function is re-declared on each render, resulting in a race condition that had other side effects. A fix for this is already proposed in Fix newlines in block editor after a user mention #41749.filteredOptions.lengthinautocomplete/index.js: This dependency triggered some extra renders, but on a single completer it didn't result in a loop.When an autocompleter loads, the
filteredOptions.lengthvalue starts off at zero, and then updates on a re-render when the available options load in. WithfilteredOptions.lengthas a dependency, this caused the effect to run again on that render.During that extra render, the callback to
setAutoCompleterUIwould get stuck re-rendering endlessly, switching between the two different completers each time.Storing
filteredOptions.lengthin a new Ref lets us remove it from the dep array. This way when the updated options load in, an additional render won't be triggered when the new number is populated, avoiding the loop.Testing Instructions
First, I'd recommend reproducing the bug using @johngodley's excellent repro steps in the original issue so you can see the loop/crash in action.
Once you've un-stuck your browser, you'll need to apply the fix in #41749 on top of this PR. That will prevent
onChangeOptionsfrom contributing to the loop. Cherry pick the commits from that PR onto this one (feel free to skip the CHANGELOG update, of course).Repeat the test by creating a new post and typing a combination of
@user +user @userautocompleters.