Experiment: try using inner blocks for the page list block #39087
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
talldan
added
[Type] Experimental
talldan
requested review from
gwwar,
jasmussen,
getdave,
adamziel and
draganescu
|
Size Change: -198 B (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
|
Impressive! Wild what a single PR can do. Took it for a quick spin: It's working rather well. Of course you can't move the blocks around since their order is defined elsewhere, but as an out-there idea: what if moving blocks around here actually affected the Now that individual blocks become available to select, one of the questions becomes what, if any, properties we allow editing for each block. Right now no appearance related tools are available. Fully aware this is a draft PR that isn't yet touching this piece, I nevertheless tried editing link description and managed to break it: Not saying I have to be able to edit these here, but it's something to consider if we go towards landing this one. Which seems like it could bring with it a bunch of improvements, even just performance wise, right? |
|
One nice-to-have thing about this approach is that, even if you wouldn't be able to edit the links, stuff like the "Copy" option in the ellipsis menu would still be available, allowing you to easily copy a navigation link from a pre-existing dynamic menu to a static one that you're working on. |
Wow, yes, that would be a very nice feature. This is giving me scary thoughts of how challenging it was to reorder classic menu items via the REST API in the navigation editor (I think it would be a similar technical challenge). But it's definitely not insurmountable. I think we probably need to move towards a solution more like the query block, where we make more use of the entity system. It would be interesting if the list of blocks were synced automatically to the page entities (and their order), and then using the block movers automatically generated the necessary unsaved changes to the order field for each page.
Yep! URL is a good example. It wouldn't be something that should be editable. But then I think we have the same issue with the Navigation Link block anyway. In an ideal world it would be connected to a page via its |
There was a problem hiding this comment.
This is working pretty well out of the box, and it's nice that it takes less code to achieve the same effect 🙂
One thing I noticed is Page List outside of Nav is now looking pretty broken when it has submenus:
We could maybe fix this by scoping the submenu styles more strictly to the nav block.
This seems to be a bug in edit: Fix for that in #39151, which I'll try to get cherry-picked into the 12.7 plugin release. |
8 tasks
7 tasks
|
I'll close this PR, as it isn't something that I'll have time to continue on, but if anyone wants to use this code as the basis for another PR, feel free. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a fairly simple experiment that attempts to use inner blocks for the Page List block in the editor. It does so by creating a locked template of Navigation Link blocks. Each block is also locked to prevent removal or moving.
The thing that prompted me to explore this is #38600, which looks at using List View to display site navigation. A shortcoming of Page List in this context is that it doesn't show its child pages in List View because they're not blocks. This resolves that, now we get to see the full page hierarchy in List View:
I think there are also advantages in code reuse. The Navigation Block is now using the defacto nav link blocks instead of reproducing their markup. It should avoid any issues with code or style drift.
It also fixes #38733.
There are some problems to solve:
Testing Instructions
Screenshots
Types of changes
Experiment
Checklist:
*.native.jsfiles for terms that need renaming or removal).