-
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
Navigation: Select dropdown encapsulation and further consolidation. #38627
Conversation
Size Change: +3.88 kB (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
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.
Thanks for taking time to improve this, Dave!
packages/block-library/src/navigation/edit/navigation-menu-selector.js
Outdated
Show resolved
Hide resolved
packages/block-library/src/navigation/edit/navigation-menu-selector.js
Outdated
Show resolved
Hide resolved
packages/block-library/src/navigation/edit/navigation-menu-selector.js
Outdated
Show resolved
Hide resolved
packages/block-library/src/navigation/edit/navigation-menu-selector.js
Outdated
Show resolved
Hide resolved
Here's the artifact from the failing e2e test. Notice how the menu is appearing to be in the placeholder state even though the test has already selected the classic menu. I think this might be because we assume the selection of the classic menu is "done" once the button is clicked whereas in fact it relies on the network. Therefore we probably need to wait for the link blocks to appear in the Nav block before saying "we're done". |
Only thing left is to work out why the e2e test has started failing. FYI it passes locally so it's likely a network issue with the loading of the menu data. |
canUserCreateNavigation: canUserCreateNavigationMenu, | ||
canUserUpdateNavigationEntity: canUserUpdateNavigationMenu, | ||
canSwitchNavigationMenu, | ||
} = useNavigationMenu(); |
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.
What if the hook returned the final names already?
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.
It doesn't...yet but yes this will require a fix when my other PR lands.
{ showManageActions && | ||
( canUserCreateNavigationMenu || | ||
canUserUpdateNavigationMenu ) && ( |
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.
that's quite a condition :D how about showManageActions && hasManagePermissions
?
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.
Updated.
This is fantastic, thank you so much @getdave – your work makes the block more readable and less error prone by the day! |
Description
This PR builds on #38179 to further consolidate and normalize all code paths around the "Select menu" dropdown that is shown in:
This PR moves all permissions checking and data fetching within the
<NavigationMenuSelector>
component and then utilises that single component in both instances (as above).This ensures all logic is the same across all areas where this UI is exposed.
Also addresses part of #37190.
Testing Instructions
The aims is that nothing changes for the block UI. It should be "as was".
Screenshots
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).