Fix select all shortcut inside widget area parents #30462
Closed
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
draganescu
requested review from
adamziel,
kevin940726,
noisysocks,
talldan and
tellthemachines
as code owners
draganescu
changed the title
|
Size Change: +195 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
My first thought while reading this is that it sounds like yet another problem with using the Widget Area block to implement widget areas 🙂 cc. @talldan |
kevin940726
reviewed
Apr 8, 2021
| @@ -45,13 +77,32 @@ function KeyboardShortcuts() { | |||
| { bindGlobal: true } | |||
| ); | |||
|
|
|||
| useShortcut( | |||
| 'core/edit-widgets/select-all', | |||
| useCallback( | |||
There was a problem hiding this comment.
Is it necessary to memoize it?
| 'core/widget-area' | ||
| ); | ||
| return { | ||
| rootBlocksClientIds: getBlockOrder( selectedParentClientId ), |
There was a problem hiding this comment.
Since we only care about the first and the last, maybe try to only expose them here so that we can avoid unnecessary re-renders.
|
|
||
| /** | ||
| * Internal dependencies | ||
| */ | ||
| import { store as editWidgetsStore } from '../../store'; | ||
|
|
||
| let selectedClientId; |
There was a problem hiding this comment.
A better "React" way of doing this is to convert this to a ref with useRef. I'm not sure why we need this variable either? Couldn't we just use newSelectedClientId?
There was a problem hiding this comment.
We can't because it's updated on render once the selection is changed. We need to maintain a reference to the "selected" block when the keyboard shortcut was fired.
There was a problem hiding this comment.
Hmm, I'm not sure I follow.
Do you mean we can't convert this to a ref or we can't use newSelectedClientId? I think either way this deserves some comments 😆.
|
I think the implementation would be a lot cleaner here if the majority of it were implemented as an action (e.g. The problem architecturally with the current implementation is that we're using Instead, we want to determine the blocks to select when the user actually presses the shortcut. Doing it that way will also be more performant as we won't be running selectors unnecessarily during render. |
|
Will be fixed by #31859 |
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.
Description
Fixes #28267. The "select all" functionality in the post editor assumes that there is no boundary block and so it defaults to selecting everthing. On the widgtets editor we have a widget area block that contains the blocks for that area and it makes no sense to select via Primary + A the blocks in another area.
This fix is also part of my investigation in fixing #19102 and it may contain a way to fix that.
I am not happy with this implementation, but it does work. The downside is creating a memory store or hardcoding a block name for determining the container.
Alternatives would be:
selectablesupports where by certain blocks will not be selectable and select all will only apply to theirinnerBlocksThe other place that has this problem is the site editor where select all is selecting across template parts which might not be expected, but at least there we don't have the visual and functional separation active in the widgets editor.
How has this been tested?
Tested locally by:
Screenshots
N/A
Types of changes
Added an overrride for the edit-widgets package of the 'core/block-editor/select-all' shortcut.
Updated the select all logic by remembering the first selection, finding the parent and preserving the list of the blocks in the top most widget area.
To Do
Checklist:
*.native.jsfiles for terms that need renaming or removal).