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

Fix Choose menu label when a menu has been deleted. #67009

Merged
merged 2 commits into from
Dec 17, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,8 @@ function NavigationMenuSelector( {
hasResolvedNavigationMenus,
canUserCreateNavigationMenus,
canSwitchNavigationMenu,
} = useNavigationMenu();
isNavigationMenuMissing,
} = useNavigationMenu( currentMenuId );

const [ currentTitle ] = useEntityProp(
'postType',
Expand Down Expand Up @@ -106,12 +107,18 @@ function NavigationMenuSelector( {
const noBlockMenus = ! hasNavigationMenus && hasResolvedNavigationMenus;
const menuUnavailable =
hasResolvedNavigationMenus && currentMenuId === null;
const navMenuHasBeenDeleted = currentMenuId && isNavigationMenuMissing;
Copy link
Contributor

Choose a reason for hiding this comment

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

In trunk we have some similar checks and others with hasResolvedNavigationMenus && isNavigationMenuMissing. I'm wondering why that difference and mostly why isn't isNavigationMenuMissing is doing this check internally in the hook.

@afercia 's comment about Specifically in this scenario, currentMenuId && isNavigationMenuMissing is true, while menuUnavailable is false. and why we weren't passing the id here are good ones. Maybe @getdave or @draganescu have more context?

Copy link
Contributor

Choose a reason for hiding this comment

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

why isn't isNavigationMenuMissing is doing this check internally in the hook

I assume you mean check for hasResolvedNavigationMenus? One of the main problems with the code of the navigation block is that it is a blueprint of all the pitfalls we've ran through as the block evolved. I remember these checks Is* and has* have been part of a "refactoring" to herd some of the repeating code.

currentMenuId && isNavigationMenuMissing

This check is very valid, I am unsure what the question is, it means: the block has a navigation id assigned but it's missing.

Copy link
Contributor

Choose a reason for hiding this comment

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

The first question is how currentMenuId && isNavigationMenuMissing and hasResolvedNavigationMenus && isNavigationMenuMissing are different. Related to this is why isNavigationMenuMissing not checking this internally, so we wouldn't need the first part of the above checks.

The other two from @afercia are:

  1. Why currentMenuId && isNavigationMenuMissing is true, while menuUnavailable is false (this is mentioned in the PR's description.
  2. why we weren't passing the id

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the easiest way to clear things up are via code, I find it unlikely somebody knows that by heart 🤷🏻 Particularly the menuUnavailable bit, which sounds like a bug?

As to why we're not passing the id I think the main reason is it wasn't meant to and probably evolved in a way in which it now seems that it should.


let selectorLabel = '';

if ( isResolvingNavigationMenus ) {
selectorLabel = __( 'Loading…' );
} else if ( noMenuSelected || noBlockMenus || menuUnavailable ) {
} else if (
noMenuSelected ||
noBlockMenus ||
menuUnavailable ||
navMenuHasBeenDeleted
) {
// Note: classic Menus may be available.
selectorLabel = __( 'Choose or create a Navigation Menu' );
} else {
Expand Down
Loading