WordPress
Pattern editing: create a "tree" view for Buttons and List blocks
Create a Tree view tab and Tree view panel in the inspector panel for content-only blocks, starting with Buttons and List blocks, to represent and navigate through child blocks (Button and List item respectively).
Use the Navigation block tree view as a guide for implementation.
The goal is to provide a confined area for users to manage the structure of these elements, allowing for easy manipulation of block hierarchies.
Note: designs for this are being worked on, so if there are any preparatory development tasks, e.g., creating the tabs, component consolidation etc, that can be done in the interim.
Good idea! Just linking another conceptual issue that's proposing exposing the list view in the sidebar in a separate tab, too, while in "real" / full block editing mode:
- https://github.com/WordPress/gutenberg/issues/73845#top
Just to keep in mind while work happens on this issue that it might need to be generalised a bit so that it could be re-used in multiple places?
I've had a look at how the List View tab is implemented. There's an allowList here that limits the tab only to the navigation block:
https://github.com/WordPress/gutenberg/blob/d3734f5e4839d0cf5ada56fedb253fae26c55116/packages/block-editor/src/components/inspector-controls-tabs/use-is-list-view-tab-disabled.js#L3
It's easy enough to open that up to other blocks, and in future it might be a block support.
The Tab's content is rendered via an <InspectorControl group="list">, pretty standard.
The code for the navigation block's ListView is here: https://github.com/WordPress/gutenberg/blob/d3734f5e4839d0cf5ada56fedb253fae26c55116/packages/block-library/src/navigation/edit/menu-inspector-controls.js#L179-L186
It does have quite a few navigation specific parts right now. Ideally a <PrivateListView> doesn't have to be added manually to each block, it's something that the block can opt into and it works the same on all blocks.
I don't know that it's a good idea to try refactoring the nav block right now, maybe that's a future task. I think it's best to develop a separate generic solution for Buttons and Social Icons and then after that we could consider if the same implementation can be used for the nav block with some extensibility points, or if the nav block overrides the default.
It'd be good to get your thoughts @getdave and @scruffian.
@talldan Thanks for thinking about this 🙇
There's certainly an argument for avoiding complex refactors to the Nav block during this cycle given all the work that's underway. I fully understand where you are coming from on this.
However, one of the aims in this cycle is to allow the Navigation block to function within the scope of the Simplified Editing project. There could be a danger that we'd diverge the approach for the other blocks leaving Navigation playing "catch up" just before release time or not having it's needs fully serviced by the generic solution. We could avoid that by carefully tracking new features being added for Buttons and Social and ensuring Navigation has parity but that's prone to human error.
Alternatively, as you suggested, it could be helpful to use the new requirements to drive the refactor of the existing PrivateListView to a generic component (not a block supports yet) which has sufficient extension points to afford flexibility for all the use cases we require.
At this point my main concern would be with the custom logic for showing LinkControl in the ListView as that is quite specific to Navigation. I can see how that might be quite challenging to refactor to be an extension point.
I would lean towards exploring the ability to reuse the existing Nav block <PrivateListView> to solve for the requirements of Social and Buttons. If we hit significant roadblocks then we can branch but ideally we should be able to develop a solution that works for all use cases.
I'm curious to hear from @jeryj as well (@scruffian is AFK) who is also deep in the weeds of Navigation.
One thing we might need is to ensure good test coverage for existing functionality in the Nav block List View before we attempt any refactors. It looks like we added that at the time which is nice
https://github.com/WordPress/gutenberg/blob/trunk/test/e2e/specs/editor/blocks/navigation-list-view.spec.js
I think it's worth exploring this from multiple angles in low fidelity ways. It will help us get more information to make a better decision. If it can meet the requirements and is similar, I prefer reusing existing components and improving them over adding a new one.
I think I'll end up doing some work within PrivateListView for the Nav block work, so I'd be interested to know what the Buttons and Social Icons flows would look like using the List View. I agree this could be used to drive the improvements.
At this point my main concern would be with the custom logic for showing LinkControl in the ListView as that is quite specific to Navigation.
Is that the popup that's triggered when using the appender? I guess it's not actually an appender menu, it's UI of the block that's inserted.
I think that would be useful for buttons, maybe social icons too, though those will almost always be external links, so options like 'Create page' wouldn't be needed.
I think I'll end up doing some work within PrivateListView for the Nav block work, so I'd be interested to know what the Buttons and Social Icons flows would look like using the List View. I agree this could be used to drive the improvements.
I expect it will be very similar to that nav block. This is the issue to have a read through - https://github.com/WordPress/gutenberg/issues/73845.
Is that the popup that's triggered when using the appender? I guess it's not actually an appender menu, it's UI of the block that's inserted.
Yes that's right 👍
https://github.com/user-attachments/assets/c62354f9-147f-4b29-838c-1848d424971f
And we have had to use some "creative" state management to get it to work there. I agree it seems like a UI of the block and luckily it looks like we determined what when we added the additionalBlockContent prop which is where the LinkControl code resides.
https://github.com/WordPress/gutenberg/blob/99d4c2f31517031d6089a5551acbf89698691423/packages/block-library/src/navigation/edit/menu-inspector-controls.js#L185
That prop seems to align with the wider requirements here for block-specific UI.