Navigation: Implement redesign of Navigation Editor - #25178
Conversation
noisysocks
added
Needs Design Feedback
|
Size Change: -1.17 kB (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
|
This looks really nice! |
|
@noisysocks There was also a discussion about adding a label to the menu select, but not sure if a firm decision had been made on that - #24875 (comment) |
|
I'm unable to get this running locally. I get the following console error when I try to visit the screen:
|
Whoops—my bad. Fixed in e414e3f. Try again now! |
|
@shaunandrews: How should this look when there are no menus? This would happen, for example, when the user is setting up a brand new site. We could automatically drop the user into the Add new flow but I worry that this doesn't make it clear to the user what they need to do. Also, the Add new and Cancel buttons wouldn't do anything useful.
|
tellthemachines
left a comment
tellthemachines
left a comment
There was a problem hiding this comment.
The design looks very good on desktop, but on mobile it's a bit weird to have the list view between the block toolbar and the blocks themselves.
The other side of this is the changed markup order has disrupted keyboard navigation: it should be possible to Shift+Tab from the block to its toolbar (just like in the post editor), and with this change Shift+Tab brings us to the list view first, and then to end of the toolbar where the block inspector toggle is.
Apart from that, only a couple of comments below 😅
|
Thanks for testing @tellthemachines! I made things look a little nicer on mobile in cb544c4 by splitting the toolbar into two rows when the viewport is small. We can't make the tab order @shaunandrews: How do you feel about moving the List view to the right of the screen? |
Co-authored-by: Kai Hao <kevin830726@gmail.com>
Co-authored-by: Kai Hao <kevin830726@gmail.com>
cb544c4 to
86440fa
Compare
tellthemachines
left a comment
tellthemachines
left a comment
There was a problem hiding this comment.
This is getting pretty close! I left a few comments.
One thing I noticed is we still have the color options on the Nav block toolbar. Shouldn't we get rid of those for this screen?
| flex-direction: column; | ||
|
|
||
| .block-editor-block-card { | ||
| order: -2; |
There was a problem hiding this comment.
Oooh we shouldn't do this, it messes up keyboard focus order.
I don't think there's a way to add items to the inspector in any position, because the slot is positioned in a specific place; perhaps the component could be changed to include another slot, but... do we really need the top level pages checkbox to be this prominent?
There was a problem hiding this comment.
Yeah, this is a total hack. We need to come up with a better way of doing this. Maybe we could add an order prop to InspectorControls. I've made a note to come back to this.
kevin940726
left a comment
kevin940726
left a comment
There was a problem hiding this comment.
Mostly looks good!
I'm not sure about the useSelect second argument though, feel free to dismiss them if they don't make sense!
|
|
||
| export default function ListView( { isPending, blocks } ) { | ||
| const [ selectedBlockId, setSelectedBlockId ] = useState( | ||
| blocks[ 0 ]?.clientId |
There was a problem hiding this comment.
What happens when blocks changes?
For example, it changes from [1, 2, 3] to [4, 5, 6]. selectedBlockId is now out of sync, should we care about this at all?
There was a problem hiding this comment.
To be honest I'm not even sure why we're using local state instead of select( 'core/block-editor' ).getSelectedBlockClientId(). Maybe @talldan knows?
There was a problem hiding this comment.
It was already this way in master, so I've made a note to come back to this later.
| const [ menuLocationsByName, setMenuLocationsByName ] = useState( null ); | ||
|
|
||
| useEffect( () => { | ||
| let isMounted = true; |
There was a problem hiding this comment.
I was wrong, this is not ideal 😓 , see https://reactjs.org/blog/2015/12/16/ismounted-antipattern.html
However, it's the best we can get, and it doesn't really matter that much in this context. Just want to note that, maybe we should add an API in apiFetch to allow canceling/aborting the request.
There was a problem hiding this comment.
Just want to note that, maybe we should add an API in apiFetch to allow canceling/aborting the request.
Good idea.
| const [ autoAddPages, setAutoAddPages ] = useState( null ); | ||
|
|
||
| useEffect( () => { | ||
| if ( autoAddPages === null && menu ) { | ||
| setAutoAddPages( menu.auto_add ); | ||
| } | ||
| }, [ autoAddPages, menu ] ); |
There was a problem hiding this comment.
Why not just set initialState to menu.auto_add?
| const [ autoAddPages, setAutoAddPages ] = useState( null ); | |
| useEffect( () => { | |
| if ( autoAddPages === null && menu ) { | |
| setAutoAddPages( menu.auto_add ); | |
| } | |
| }, [ autoAddPages, menu ] ); | |
| const [ autoAddPages, setAutoAddPages ] = useState( menu.auto_add ); |
Or better, just derive state from props.
| const [ autoAddPages, setAutoAddPages ] = useState( null ); | |
| useEffect( () => { | |
| if ( autoAddPages === null && menu ) { | |
| setAutoAddPages( menu.auto_add ); | |
| } | |
| }, [ autoAddPages, menu ] ); | |
| const autoAddPages = menu.auto_add; |
Since saveMenu updates menu anyway, what's the benefit of introducing a new state here?
Do we want it to always defaults to false?
There was a problem hiding this comment.
The local state is so that the checkbox below can be a controlled component. We can't initialise this state to menu.auto_add because menu is null when the component mounts and when the REST API request is pending.
We could remove the useSelect() by passing menu as a prop instead of menuId but it doesn't change much because the menu prop is still potentially null.
There was a problem hiding this comment.
Never mind me. I see what you mean now. Yes, we should be able to rely on @wordpress/data to persist this state.
There was a problem hiding this comment.
Hm. Annoyingly, when I do this, getMenus() starts a GET /menus request immediately after saveMenu() is dispatched. This clobbers the auto_add value that we just saved because the backend hasn't had a chance to persist the new value to the database.
I'll need to dig into why @wordpress/data does this and fix it there. It should be smart enough to not issue unnecessary API requests. I've made a note to come back to this later.
| onClick={ () => { | ||
| if ( | ||
| // eslint-disable-next-line no-alert | ||
| window.confirm( |
There was a problem hiding this comment.
Should we be using window.confirm? If this is temporary code only, maybe we should add a FIXME comment above?
|
I just noticed the layout is broken at < 780px:
|
|
@tellthemachines: 1b668fb should fix that. |
Late to the party but I'd definitely second this. There should be better affordance across all the new UIs and wherever theres a toolbar, one single Shift+Tab should take from the edited object to its toolbar. For example, right now when I select part of a menu item because I want to make it bold:
Will create a new issue. |
8 participants
Implements the broad strokes of the Navigation Editor redesign described in #24875.
Closes #25010. Closes #25014.
I focused mainly on layout and component structure changes. The smaller details described in #24875 can be implemented in smaller follow-up PRs. Ultimately this turned into a near-rewrite of the screen.
What's in this PR
What's NOT in this PR
Tasks to do after merge
InspectorControls. See Navigation: Implement redesign of Navigation Editor #25178 (comment).getSelectedBlockClientId()? See Navigation: Implement redesign of Navigation Editor #25178 (comment).@wordpress/dataissue. See Navigation: Implement redesign of Navigation Editor #25178 (comment).