Navigation Panel: Hide Page List parent when it's the only item in the menu

[jameskoster]

When a menu only contains a Page List block, the parent is kind of superflous, and makes navigating around a bit tedious (you have to manually re-open the Page List every time):

page.list.mp4

Since you cannot really do anything with the Page List in this scenario (except remove it, which seems ill-advised), perhaps we can hide it and just display the children as if they were top-level?

[getdave]

This makes sense to me in the limited context of Browse Mode sidebar only. In other contexts we need Page List parent to be able to manage controls on the Page List block itslef (such as setting the "parent").

I am conscious that this may introduce yet another fork in the Offcanvas Editor logic which will be accounting for a specific placement.

[jorgefilipecosta]

On a site where the page list is the only item on the menu.
The actions possible are: remove the page list.
And add another block.

I guess with this change we just show a list of pages without any action possible besides inserting another block which is a sibling of the page list?

I guess a possible way to implement this is on the browse mode sidebar to detect cases where page list is the only block, and if that is the case pass to the off-canvas editor only each page list item as the top block?

[youknowriad]

What should happen to the "inserter" in that case: Should it insert blocks within the page list block or after it?

[jameskoster]

Is Page List capable of entertaining different child blocks? 🤔

I can't seem to place blocks inside it in the Editor, so assuming it's not, we might need to expose the structure when more blocks are added. Otherwise it would be confusing why you couldn't place blocks between the page links.

[jorgefilipecosta]

What should happen to the "inserter" in that case: Should it insert blocks within the page list block or after it?

Hi @youknowriad,
The page list block does not support any block inside. For now, what my PR does is insert blocks after the page list. In that case, the menu becomes complex and the page-list is exposed.
PR available at #48725.

[draganescu]

I tried this in 48971 for when the page list block is also a child of a navigation link, in various ways including copying from Jorge in 48725. It's complicated by the fact that:

• the page list block does not have the children in the clientIds tree, since it's self building based on querying for pages
• the page list block has page list item children which cannot be children of navigation link
• the off canvas component works with a tree of clientIds so we need to query the state to figure out when a page list is in that tree and then replace it with something else (maybe some fake navigation link items)

Highly involved. Not the way blocks currently operate. I wonder if this need is signaling that we need to reinvent managing pages via the navigation block, instead of using the page list block? We could update the navigation link block to know if it is a page? Even the navigation block could have a system to build navigation link trees based on the page tree.

Having a site structure "entity" would also be nice so that when users reorder, add, delete, pages they are presented with edits to "site structure" which reflect in their pages being reordered, created, deleted?

[jameskoster]

I don't know if we need to unilaterally hide Page List. It still has practical uses in more elaborate menus.