Skip to content
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

Navigation: Implement redesign of Navigation Editor #25178

Merged
merged 34 commits into from
Sep 11, 2020

Conversation

noisysocks
Copy link
Member

@noisysocks noisysocks commented Sep 9, 2020

Implements the broad strokes of the Navigation Editor redesign described in #24875.

Closes #25010. Closes #25014.

25178-pr-nav-screen

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

  • Substantial refactor of Layout so that new components can access the state they need.
  • New Header and Toolbar components.
  • Manage Locations has been rewritten and is now a popover.
  • Add New form has been rewritten and now appears inline in the toolbar.
  • Automatically Add Pages checkbox and Delete menu button has been rewritten and now appears in the block inspector.

What's NOT in this PR

  • List View design updates.
  • Placeholder updates.
  • Block Inspector updates.
  • Toolbar updates including ability to rename a menu.

Tasks to do after merge

@github-actions
Copy link

github-actions bot commented Sep 9, 2020

Size Change: -1.17 kB (0%)

Total Size: 1.2 MB

Filename Size Change
build/annotations/index.js 3.67 kB -2 B (0%)
build/block-directory/index.js 8.54 kB +46 B (0%)
build/block-editor/index.js 128 kB -89 B (0%)
build/block-library/index.js 139 kB +42 B (0%)
build/blocks/index.js 47.8 kB +190 B (0%)
build/components/index.js 200 kB +18 B (0%)
build/compose/index.js 9.68 kB -1 B
build/core-data/index.js 12.3 kB -1 B
build/data/index.js 8.54 kB +1 B
build/dom/index.js 4.47 kB -2 B (0%)
build/edit-navigation/index.js 10.7 kB -1.05 kB (9%)
build/edit-navigation/style-rtl.css 868 B -293 B (33%) 🎉
build/edit-navigation/style.css 871 B -292 B (33%) 🎉
build/edit-site/index.js 19.3 kB -15 B (0%)
build/edit-widgets/index.js 12.2 kB +102 B (0%)
build/edit-widgets/style-rtl.css 2.55 kB +94 B (3%)
build/edit-widgets/style.css 2.55 kB +94 B (3%)
build/editor/index.js 45.6 kB -4 B (0%)
build/format-library/index.js 7.72 kB +1 B
build/i18n/index.js 3.56 kB -2 B (0%)
build/keyboard-shortcuts/index.js 2.52 kB -1 B
build/keycodes/index.js 1.94 kB -1 B
build/list-reusable-blocks/index.js 3.12 kB +1 B
build/notices/index.js 1.79 kB +2 B (0%)
build/nux/index.js 3.4 kB -3 B (0%)
build/rich-text/index.js 13.9 kB -1 B
build/server-side-render/index.js 2.77 kB -1 B
build/url/index.js 4.06 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/api-fetch/index.js 3.41 kB 0 B
build/autop/index.js 2.82 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 953 B 0 B
build/block-directory/style.css 952 B 0 B
build/block-editor/style-rtl.css 11.1 kB 0 B
build/block-editor/style.css 11.1 kB 0 B
build/block-library/editor-rtl.css 8.68 kB 0 B
build/block-library/editor.css 8.68 kB 0 B
build/block-library/style-rtl.css 7.59 kB 0 B
build/block-library/style.css 7.58 kB 0 B
build/block-library/theme-rtl.css 754 B 0 B
build/block-library/theme.css 754 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/components/style-rtl.css 15.5 kB 0 B
build/components/style.css 15.5 kB 0 B
build/data-controls/index.js 1.29 kB 0 B
build/date/index.js 31.9 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/edit-post/index.js 305 kB 0 B
build/edit-post/style-rtl.css 6.26 kB 0 B
build/edit-post/style.css 6.25 kB 0 B
build/edit-site/style-rtl.css 3.06 kB 0 B
build/edit-site/style.css 3.06 kB 0 B
build/editor/editor-styles-rtl.css 492 B 0 B
build/editor/editor-styles.css 493 B 0 B
build/editor/style-rtl.css 3.81 kB 0 B
build/editor/style.css 3.81 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 621 B 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.32 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.41 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/viewport/index.js 1.85 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@paaljoachim
Copy link
Contributor

paaljoachim commented Sep 9, 2020

This looks really nice!
Based on what @afercia Andrea mentioned. Perhaps we should move the Save button all the way to the right? Switching the order of the settings and Save button. #24875 (comment)

@talldan
Copy link
Contributor

talldan commented Sep 9, 2020

@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)

@shaunandrews
Copy link
Contributor

I'm unable to get this running locally. I get the following console error when I try to visit the screen:

image

@noisysocks
Copy link
Member Author

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!

@noisysocks
Copy link
Member Author

@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.

Screen Shot 2020-09-10 at 13 04 06

Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😅

packages/edit-navigation/src/components/editor/index.js Outdated Show resolved Hide resolved
packages/edit-navigation/src/components/toolbar/index.js Outdated Show resolved Hide resolved
@noisysocks noisysocks marked this pull request as ready for review September 10, 2020 07:08
@noisysocks
Copy link
Member Author

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 1) Toolbar; 2) Visual view; 3) List view unless we move the List view to the right of the screen or break the expectation that screen readers announce elements in the same order that they appear visually.

@shaunandrews: How do you feel about moving the List view to the right of the screen?

@noisysocks noisysocks force-pushed the update/navigation-editor-redesign branch from cb544c4 to 86440fa Compare September 10, 2020 07:44
Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

packages/edit-navigation/src/components/editor/index.js Outdated Show resolved Hide resolved
packages/edit-navigation/src/components/editor/style.scss Outdated Show resolved Hide resolved
packages/edit-navigation/src/components/header/index.js Outdated Show resolved Hide resolved
packages/edit-navigation/src/components/header/style.scss Outdated Show resolved Hide resolved
flex-direction: column;

.block-editor-block-card {
order: -2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@kevin940726 kevin940726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest I'm not even sure why we're using local state instead of select( 'core/block-editor' ).getSelectedBlockClientId(). Maybe @talldan knows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was already this way in master, so I've made a note to come back to this later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was @adamziel's change, #22705 should be the issue relating to the code.

const [ menuLocationsByName, setMenuLocationsByName ] = useState( null );

useEffect( () => {
let isMounted = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to note that, maybe we should add an API in apiFetch to allow canceling/aborting the request.

Good idea.

Comment on lines +12 to +18
const [ autoAddPages, setAutoAddPages ] = useState( null );

useEffect( () => {
if ( autoAddPages === null && menu ) {
setAutoAddPages( menu.auto_add );
}
}, [ autoAddPages, menu ] );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just set initialState to menu.auto_add?

Suggested change
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.

Suggested change
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?

Copy link
Member Author

@noisysocks noisysocks Sep 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind me. I see what you mean now. Yes, we should be able to rely on @wordpress/data to persist this state.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be using window.confirm? If this is temporary code only, maybe we should add a FIXME comment above?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't yet have a better alternative. See #16583. I don't think a FIXME is very necessary because it will come up when the hypothetical future fixer of #16583 searches for window.confirm.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I didn't know #16583 exists, thanks!

@tellthemachines
Copy link
Contributor

I just noticed the layout is broken at < 780px:

Screen Shot 2020-09-11 at 3 36 24 pm

@noisysocks
Copy link
Member Author

@tellthemachines: 1b668fb should fix that.

Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@draganescu draganescu merged commit adac4e7 into master Sep 11, 2020
@draganescu draganescu deleted the update/navigation-editor-redesign branch September 11, 2020 07:58
@github-actions github-actions bot added this to the Gutenberg 9.0 milestone Sep 11, 2020
@afercia
Copy link
Contributor

afercia commented Sep 14, 2020

it should be possible to Shift+Tab from the block to its toolbar (just like in the post editor)

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:

  • the first Shift+Tab brings me to the focusable list item that wraps the contenteditable
  • the second Shift+Tab brings me to the "Save" button
  • the third Shift+Tab brings me to the "Block inspector" button, which technically isn't part of the toolbar
  • finally, the fourth Shift+Tab brings me to the real toolbar, where arrows navigation and roving tabindex work as expected

Will create a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update the "Create menu" flow Move "auto-add pages" into the Navigation block's Inspector
8 participants