Thinking about this some more, I don't think a 'Menu' block is actually needed, the editor can just use menu items directly. I might consider removing 'Menu'.

Size Change: +5.13 kB (0%)

Total Size: 1.05 MB

_{compressed-size-action}

I've implemented the placeholder from #23953 in this PR as it was very easy to do without the technical blockers of having to extend the nav block.

I think this offers a lot of opportunities:

• Exploring using useEntityProp for editing menu item properties (similar to how a block like PostTitle works), which wouldn't be possible in the navigation link block. This architecture would make it easy to save only edited menu items.
• There has been significant feedback about the the lack of UI clarity for nested menus. This can be iterated more quickly, without having to work around how the nav block works.
• It'll be easier to show validation issues for menu items, including if there's an error from the REST API.
• The dedicated blocks have more scope for supporting backwards compatibility (especially around extensibility).
• The placeholder and block styles are already significantly improved in this PR, and it didn't take much effort.
• This PR already removes a lot of the more fragile code in the navigation editor, and there are more opportunities
• It'd be interesting to look into completely removing the 'Menu' block, thinking about it the block might be unnecessary, a user only edits menu items.
• The navigation block itself can be iterated on without concern for navigation editor support.

I think there could be some questions:

• Are these dedicated block less portable? I don't think so, as copy/paste between editors could still be handled using something like a raw transform. Or the transform system could be extended to support converting from an unsupported block to a supported one.
• How would the theme opt-in feature work? I think if the user has an existing 'Menu' block and the theme opt-in is detected, the editor could provide an option to convert/upgrade to a navigation block. The menu block also gives the user the option to stick with their classic menu if that's not what they desire.

Thanks for exploring this 🏅. It works well at first glance.

Here are some responses. I feel like we'll need to consider this very carefully...

• Exploring using useEntityProp for editing menu item properties (similar to how a block like PostTitle works), which wouldn't be possible in the navigation link block. This architecture would make it easy to save only edited menu items.

I'm not clear on how/why it's not possible? What benefit does it bring saving only edited items? Would you say this is a major win or a nice side effect?

• There has been significant feedback about the the lack of UI clarity for nested menus. This can be iterated more quickly, without having to work around how the nav block works.

I see now that this PR drops the Nav Block entirely within the Nav Editor. Is this effectively a "Classic" Navigation block?

• It'll be easier to show validation issues for menu items, including if there's an error from the REST API.

How is it easier? I'm genuinely curious.

• The dedicated blocks have more scope for supporting backwards compatibility (especially around extensibility).

How do they have better scope for support this? What specifically would be easier?

• The placeholder and block styles are already significantly improved in this PR, and it didn't take much effort.

I agree the placeholder was much nicer 👍

• This PR already removes a lot of the more fragile code in the navigation editor, and there are more opportunities

I'm guessing this is mostly not having to disable all the "unwanted" Nav block features right?

• It'd be interesting to look into completely removing the 'Menu' block, thinking about it the block might be unnecessary, a user only edits menu items.

I'm confused. Are you suggesting a Menu Item blocks as children of the Navigation block?

• The navigation block itself can be iterated on without concern for navigation editor support.

Only if we don't use the Navigation block and utilise this new Menu block instead. Otherwise we'll have to make sure Nav block changes work for the Menu block.

• How would the theme opt-in feature work? I think if the user has an existing 'Menu' block and the theme opt-in is detected, the editor could provide an option to convert/upgrade to a navigation block. The menu block also gives the user the option to stick with their classic menu if that's not what they desire.

What happens if we decide to allow for block based themes to opt into block based rendering of menus. Wouldn't Themers now need to write styles for the Menu block as well as the Navigation block? It's another area of inconsistency and complexity to be considered.