-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
WIP Off Canvas Navigation: Edit Button #45575
Conversation
Open in CodeSandbox Web Editor | VS Code | VS Code Insiders |
Size Change: +1.01 kB (0%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
Cool stuff 🙇🏻 this is the very next step needed before the drill down system can be added to the experiment. This adds an edit button to the list view. Right now when I click on it I get the dialogue for converting a non existent page list block to navigation links 🐳edit-button-convert.mp4That dialogue should only appear if there is a page list block used in the navigation menu and the user wants to edit a link in the page list. Otherwise when clicking the edit button a panel with the detail selected appears (a la global styles). But the icon, positioning and interaction feels very neat! 👏🏻 |
Thanks for the clarification, I'll be sure to update it. One edge case I found was that we only offer the edit button on Page List blocks with fewer than 100 children: gutenberg/packages/block-library/src/page-list/edit.js Lines 26 to 28 in 6f0e046
My thought is to disable the button with an explanation in that situation, but that's a lower priority. That's what I'm working on next. I'm going to try to reuse the InspectorPanel slots for the slide-over. In the video I noticed that the Page Link edit example is a bit different from the InspectorPanel. Right now I am thinking we can use InspectorPanel initially and possibly create another slot for off-canvas editing to add things like the URL field. |
Excellent. One thing that would be good is to explore the sliding UI in a new PR for clarity and ease of review. Also apparently all my PRs for the list view have been merged and so you cans base your work on trunk now. |
One note for the "back" interaction is that we should build it in a way that can apply to any scenario. e.g. if block is passed as prop to inspector show back button that navigates back to that block |
7b96174
to
4cc5c78
Compare
@draganescu I squashed my commits to rebase off of trunk, so the diff should be much more usable. Good call on splitting up the sliding panel part from this, it'll be much easier to land this with the fixes for the Page List and follow up with the edit panel for individual items. |
4cc5c78
to
ee39738
Compare
@draganescu I'm not seeing links underneath the page list. Is that something that should be working? Or should I add that to this PR? |
Page list does not show its contents in the list view. That is a feature of the page list block that should be added in the future - in a PR specifically for that as it's about that block not about the navigation block. |
Connected to this, I created a PR to add the URL field to the Navigation Link inspector controls panel: #45751 |
@draganescu We've moved the panels out of scope for this PR, are there any more features we need before we merge this? |
packages/block-editor/package.json
Outdated
@@ -39,6 +39,7 @@ | |||
"@wordpress/blocks": "file:../blocks", | |||
"@wordpress/components": "file:../components", | |||
"@wordpress/compose": "file:../compose", | |||
"@wordpress/core-data": "file:../core-data", |
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 block editor shouldn't have core data as a dependency as Core Data is WP specific whereas block editor is platform agnostic.
}; | ||
|
||
const ConvertToLinksModal = ( { onClose, clientId } ) => { | ||
const { records: pages, hasResolved: pagesFinished } = useEntityRecords( |
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.
We will need to find another way to grab the Pages records from Core.
Likely you will need to pass them as part of the block editor settings via the relevant edit/*
store. This way the same code could be utilised across the block and this off canvas list view.
Here is an example of using @wordpress/editor
to get information about Core and pass it into the block editor settings for retrieval thereby avoiding the need for the @wordpress/core-data
dep in the @wordpress/block-editor
package.
userCanCreatePages: canUser( 'create', 'pages' ), |
__experimentalCreatePageEntity: createPageEntity, |
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, I'll see how I can get the data we need into the component without calling core-data
directly.
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.
Previous review should have been blocking to ensure we don't accidentally commit @wordpress/core-data
as a dependency of @wordpress/block-editor
.
See my previous review for details.
It was easier to nuke the commit history than to manually sync a bunch of commits, so this is all the commits in the branch squashed
a2f7662
to
4f94b25
Compare
@georgeh I'm working on removing the |
Ok I suggest we down tools on this one until we're absolutely clear that
@draganescu is working on making the child items of Page List visible in List View so that may invalidate the need for this PR. |
); | ||
}; | ||
|
||
const BlockEditButton = ( { label, clientId } ) => { |
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.
As things stand I'm pretty sure this code is going to run for all types of blocks. It's actually only required for the Page List block. It will need to be conditionalised.
FYI I decided a good first step would be to land the edit button on it's own. Therefore I spun out #45815. I've put @georgeh down as co-author on that PR as much of the work was borrowed from this one. In the future we may need to implement the work from this PR around Auto Menu conversion. Hopefully not as it adds complexity but at least we have it available should we require it. |
What?
Partially addresses #45442
Why?
This will simplify editing menu items from the navigation inspector
How?
This is based off of the (closed) #44534 branch and will be rebased once the follow-up PRs get merged. As of e1b012a the only branch-specific changes are in
packages/block-editor/src/components/off-canvas-editor/block-edit-button.js
Trigger block inspector overlay for other navigation child blocksmoving to follow-up PRTesting Instructions
Screenshots or screencast