-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add navigator for nav block #17265
Add navigator for nav block #17265
Conversation
<BlockNavigationList | ||
blocks={ [ block ] } | ||
selectedBlockClientId={ selectedBlockClientId } | ||
selectBlock={ selectBlock } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Selecting the block works well in the current Block Navigation Menu accessible from the top toolbar. The PopOver closes and the correct block becomes selected.
In a modal this makes less sense. Currently it makes the modal close (though not sure why). I think this is the biggest issue with the experience as it stands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I suppose it makes sense that selectBlock
is causing the focus to shift and that's closing the modal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The navigator view is not meant for navigation only, it is, or it should be a way to build and edit the menu. We could make a double click action or some other way to select a deeply nested item and return to the navigation block edit view, for example a la dev tools "inspect" :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sold on using a modal for this functionality as it stands. What @draganescu is describing - that it should be a way to build and edit the menu - would make more sense as a modal, but on the other hand shouldn't the block itself provide that drag/drop/edit capability already?
If this navigator is replicating the top one, it would be better to have it as a dropdown, exactly like the top one.
Another thing I notice with the modal is when closing it with esc
focus goes to the block wrapper (not sure if that's what it's called - I mean the element that gets focus when navigating blocks with the arrow keys) whereas I would expect it to go back to the initial button, or at least to the next focusable element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is definitely that this is a data view, and will be used for re-arranging things, potentially adding new blocks. I plan to do this incrementally though and not on the same PR. It's a good question about where block selection fits into this modal.
Another thing I notice with the modal is when closing it with esc focus goes to the block wrapper (not sure if that's what it's called - I mean the element that gets focus when navigating blocks with the arrow keys) whereas I would expect it to go back to the initial button, or at least to the next focusable element.
Good catch, will see if I can figure out what's going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
esc
was indeed triggering navigation mode, and with the way the escape key event was working for modals (as a global event binding) there was no way of stopping propagation.
I've re-arranged things in fc2d299, and it's an improvement, but it still seems like the wrong icon is focused when pressing escape.
I'll have to bring those changes to the modal to a separate PR and will continue looking into the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm yeah, seems like focus is always returned to the previous focusable element rather than the next one. Agree it's a lot better than it was 😄
Apart from this modal the same problem was also affecting the one that pops up for "Resolve" on an invalid block. That one is also now returning focus to the previous focusable element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a fix locally and some general modal fixes on #17297. Will bring them all together once that's merged.
Had a look at the that invalid block modal, and it looks like when the modal is open, the button that opens it is no longer rendered, so I think that causes the focus return not to work.
return ( | ||
<Fragment> | ||
{ isNavigationListOpen && ( | ||
<Modal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have expected that the Navigation block would use both modal and the Block navigator to make up the UX in such way. Is this better to have the block navigator
be a modal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it might be good to not have the modal render as a child of the block toolbar, considering how the toolbar likes to unmount quite a lot.
Also keen to not add too much code to the main Navigation Menu edit component though or make this any more complicated than it needs to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've switched to using a hook for the block navigator and I'm now rendering the modal outside of the toolbar. It probably won't stay this way. I could imagine that if the navigator is something we'd consider using for other blocks, then the modal would be moved to the editor itself and be opened using an action.
This is a pragmatic solution for now.
<BlockNavigationList | ||
blocks={ [ block ] } | ||
selectedBlockClientId={ selectedBlockClientId } | ||
selectBlock={ selectBlock } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The navigator view is not meant for navigation only, it is, or it should be a way to build and edit the menu. We could make a double click action or some other way to select a deeply nested item and return to the navigation block edit view, for example a la dev tools "inspect" :)
This is a great start, thanks! |
This is really great, from a design review perspective it work as expected so the feedback is 👍. I'll give a review to tick that box, but it does make me think iterating this interface will help but that's separate from this issue, it's in which is great! Thanks for all the awesome work here @talldan. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on using an existing design, approving the design and removing design feedback label.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how useful this view is for the nav, given that all the items have the same name. It'll be quite hard to make sense of anything but a very simple structure with very few elements.
Also, had a look at this in IE 😅
This seems to be caused by block-editor-block-toolbar__slot
being set to display: inline-block
, and I think that is because having position: absolute
set on its parent breaks the layout even more if the slot is set to flex
. I wonder if we really need the toolbar to be absolutely positioned though?
@@ -122,6 +122,10 @@ Undocumented declaration. | |||
|
|||
Undocumented declaration. | |||
|
|||
<a name="BlockNavigationList" href="#BlockNavigationList">#</a> **BlockNavigationList** | |||
|
|||
Undocumented declaration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice there's a bunch of Undocumented declaration
s in this file, shouldn't they be documented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know to be honest. I think originally undocumented components didn't show up in the docs.
I don't particularly want to encourage outside use of this component while it's newly extracted and only being used for an experimental block. Perhaps I should make the component itself experimental. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something changed with how the docs are generated. Probably not an issue for this PR!
<BlockNavigationList | ||
blocks={ [ block ] } | ||
selectedBlockClientId={ selectedBlockClientId } | ||
selectBlock={ selectBlock } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sold on using a modal for this functionality as it stands. What @draganescu is describing - that it should be a way to build and edit the menu - would make more sense as a modal, but on the other hand shouldn't the block itself provide that drag/drop/edit capability already?
If this navigator is replicating the top one, it would be better to have it as a dropdown, exactly like the top one.
Another thing I notice with the modal is when closing it with esc
focus goes to the block wrapper (not sure if that's what it's called - I mean the element that gets focus when navigating blocks with the arrow keys) whereas I would expect it to go back to the initial button, or at least to the next focusable element.
@tellthemachines that was discussed in slack (#design) last week. The plan is to come up with some sort of concept where a block can specify which of its attributes could be used as "display name". Menu Item could say |
…-editor package root
fc2d299
to
6fe0504
Compare
Now that #17297 has been merged, the issue with navigator mode being triggered should be resolved and focus should be returned to the correct place after closing the modal. I think it's good for a re-review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good! Left a couple of tiny questions, more out of curiosity than anything else.
@@ -122,6 +122,10 @@ Undocumented declaration. | |||
|
|||
Undocumented declaration. | |||
|
|||
<a name="BlockNavigationList" href="#BlockNavigationList">#</a> **BlockNavigationList** | |||
|
|||
Undocumented declaration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something changed with how the docs are generated. Probably not an issue for this PR!
* Safari+VoiceOver won't announce the list otherwise. | ||
*/ | ||
/* eslint-disable jsx-a11y/no-redundant-roles */ | ||
<ul className="editor-block-navigation__list block-editor-block-navigation__list" role="list"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the two almost identical classnames? Only block-editor-block-navigation__list
has CSS attached.
<li key={ block.clientId }> | ||
<div className="editor-block-navigation__item block-editor-block-navigation__item"> | ||
<Button | ||
className={ classnames( 'editor-block-navigation__item-button block-editor-block-navigation__item-button', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see there's a pattern. Are some of these classes there for backward compatibility reasons or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tellthemachines Yep, it's for backwards compatibility. Previously all these components were in the editor package, but were moved to the block-editor package.
Thanks for the code reviews. 🎉 |
Nice work on this! 😍 |
@@ -12,6 +12,7 @@ export { default as BlockEdit } from './block-edit'; | |||
export { default as BlockFormatControls } from './block-format-controls'; | |||
export { default as BlockIcon } from './block-icon'; | |||
export { default as BlockNavigationDropdown } from './block-navigation/dropdown'; | |||
export { default as BlockNavigationList } from './block-navigation/list'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How confident are we to expose this as a public API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@youknowriad It is difficult to see how this block navigator will evolve at the moment. While the api for this component is pretty clean, I could imagine it not being needed to be exposed in the future as a component/api more tailored for individual blocks is introduced.
I suppose a strategy could be to make a duplicate component in the block library for the navigation block, develop that, and then once it's a bit clearer look at moving those improvements back to the block-editor package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's better to mark it "experimental" for the moment right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@youknowriad here's a pr for that #17446
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome thank you.
Description
Fixes #16812, adds Block Navigation to the Navigation Block.
I've called it 'Block Navigator', but the name clash seems like a little issue that might need to be resolved.
Changes:
BlockNavigationList
as a component from@wordpress/block-editor
BlockNavigatorModal
component in the navigation block's folder and integrate.How has this been tested?
Manual testing
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: