Great work here. The upgrade to the panel is huge and aligns with our wider requirements for simplified editing because it allows users to utilise the Editable List View to edit Nav Menus with functionality parity.

However, it's absolutely key that we communicate when we're linking to an internal entity vs an external link.

Whilst I really enjoy the preview of the external link I am finding it hard to distinguish between when a link is to an internal entity (e.g. Post / Page) vs an external URL. That will be a problem for users and reduce the utility of this UI in resolving real world problems we identified during user testing.

To resolve this, I think the best route is as follows:

• ship a version of this which only uses this preview for entity links. External URLs show just the raw URL
• once merged, follow up with some explorations in using the preview for all link types but add visual affordances to clearly disambiguate the two types. Key elements we need include:
  • entity type indicator (Post, Page...etc)
  • post status indicator (Published, Draft...etc) - this one is required regardless
  • external URL icon (we have this)

As part of any preview for external URLs we'd first need to enhance the url-details REST API endpoint to be more reliable in fetching the correct details. This will require using the HTML API instead of regex to parse the site HTML.

The approach above allows us to ship value early and then follow up with explorations.

Thanks again for the great work exploring routes here.

Nice work here 👏 The UI is getting really close.

In terms of implementation, I'm not convinced this should be a sub component of LinkControl. This UI is effectively a wrapper around LinkControl itself so it feels unusual that it is a sub component.

This feels similar to how we avoided using Popover inside LinkControl and instead required consumers to provide that themselves.

I would generally be in favour of creating a private block editor component which is not called LinkControl* (LinkPicker?) and instead has a more generic name. It can then consume the necessary parts of LinkControl (which we could expose as private APIs for now where necessary) or just the entire LinkControl component.

The benefit of this approach is that if/when we replace LinkControl we can swap out the "link picker" bit of the UI with the new implementation.

I also wonder, given that they are fairly significant changes to data handling, whether it's possible to extract some of the changes in shared to standalone PRs? LMK if you think that makes everything too complex or whether we'd have more confidence shipping in smaller chunks?

Thanks again 🙇