Closed
Conversation
|
Size Change: +80 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
Contributor
Author
|
There may also be a way to fix this in I don't mind looking at that as a separate task. |
youknowriad
reviewed
Mar 26, 2021
| targetRootClientId, | ||
| targetBlockIndex, | ||
| insertBlocks | ||
| onDrop: useCallback( |
Contributor
There was a problem hiding this comment.
If I'm understanding properly the purpose of the PR, I think we can avoid the useCallback entirely and avoid having the callback as a dependency. Instead we can just keep the latest value of the callback in a ref and call the ref in the callback.
We use this technique in several hooks already and I believe @ellatrix built a reusable hook somewhere to keep the ref "fresh" for us, right?
Member
There was a problem hiding this comment.
We do this in several places, yes, but I don't think we have a utility function for it yet.
grzim
reviewed
Mar 26, 2021
| * | ||
| * @param {string} targetRootClientId The root client id where the block(s) will be inserted. | ||
| * @param {number} targetBlockIndex The index where the block(s) will be inserted. | ||
| * @param {Object} dropEventData Block drop event data. |
Contributor
There was a problem hiding this comment.
Is there any way to make this type more specific?
| * A function that returns an event handler function for block-related file drop events. | ||
| * An event handler function for block-related file drop events. | ||
| * | ||
| * @param {Array} files The files array from the drop event. |
Contributor
There was a problem hiding this comment.
Here the same - if it is possible, I think it would be better to add a more specific type
Contributor
Author
|
Thanks - I planned to give that a review today, but will probably be tomorrow now. |
Contributor
Author
|
Closing as this has been fixed by #30310 |
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.
Description
useDropZonecan end up in a constant cycle of adding and removing dropzone callbacks if the event handlers passed to it aren't stable. It uses and effect for adding and removing, with dependencies on the callbacks:gutenberg/packages/components/src/drop-zone/index.js
Lines 30 to 53 in c62ccd8
This seems to have been a problem for a while with the callbacks returned from
useOnBlockDrop, which doesn't useuseCallbackand even if it did, the callbacks would still be unstable every time thetargetRootClientIdandtargetBlockIndexchange while dragging to different areas on a page:gutenberg/packages/block-editor/src/components/use-on-block-drop/index.js
Lines 243 to 264 in c62ccd8
The change in this PR makes it so that the callbacks returned from
useOnBlockDropare stable by using minimising what the callbacks it returns do. The callbacks now set state for the data returned from the drop event, and a separate effect handles the actual dropping.This may lead to some performance benefits, but I think it mainly solves and issue where sometimes the dropzone target indicator can flicker between two separate dropzones (e.g. if there's another drop zone for nested blocks).
How has this been tested?
Not sure what options there are for automated testing for this kind of change
To reproduce the original issue
dropZones.add(https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/drop-zone/index.js#L41) anddropZones.remove(https://github.com/WordPress/gutenberg/blob/trunk/packages/components/src/drop-zone/index.js#L43).In this branch: In this branch the console logs happen infrequently.
In
trunk: console logging happens lots, even when not dragging and dropping 😬Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: