Make Nav Link Block text also editable from within the hyperlinklink creation UI

[getdave]

Experimental.

In the current Navigation Block, it could be argued that there is something of a disconnect between adding link text and creating the hyperlink destination of the link. when creating a Nav Link.

To add a hyperlink you interact with a LinkControl popover. This affords the ability to add a URL by direct entry or searching for an existing Post. However it does not enable editing of the link text itself.

To edit link text you need to switch away from the LInKControl popover and edit within the Block richtext directly. Whilst it is obviously desirable to retain the direct manipulation pattern established on blocks, it can feel a little clunky (and somewhat confusing) to have to switch between hyperlink UI and the block itself in order to create a link.

This PR is an experiment to see whether introducing the ability to edit the Nav Item text from within the hyperlink UI as well as the block richtext would improve the usability.

This follows established UI patterns such as that found in Google Docs (see screenshot below) which enables manipulation of the link text within the hyperlink UI:

I'm expecting that this will be rejected on the grounds of breaking the direct manipulation paradigm, but I felt it was worth exploring so we can at least rule it out and have documented evidence of this process having occurred.

Please note there is a currently a major bug in this implementation whereby editing the text within the hyperlink UI will cause focus to immediately jump back to the block richtext. This is likely due to a "bug" in RichText which would need to be fixed in order for this to work (cc @ellatrix ). Therefore please suspend disbelief when testing this PR or just take the screenshot at face value.

How has this been tested?

Manual for now.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[WunderBart]

This follows established UI patterns such as that found in Google Docs

I think it's a good pattern in a scenario when a user doesn't have the ability to freely edit the text directly from the editor. Like in Google Docs - once you delete the first or the last character of the created link, you won't be able to add it back unless starting from the middle of the text or using the popover:

In our current (production) implementation, we seem to have that ability (arrow-left after backspace):

I still think it can nicely improve the editing experience though. For ex. tab-rotating between the text->URL->submit while the popover is open (like in the Google Docs one) has a good feel for me. I like the fact there that the popover doesn't get out of focus accidentally, so I can close it when I'm done editing.

[getdave]

When applying @ellatrix's fix to RichText focus, we get the following:

Once this lands we can rebase this PR.

[getdave]

@mtias This is purely an experiment I did in my free time, but I'm keen to see what you think because I have a feeling you won't be in favour of this approach and I don't want to spend further time on it if you feel it's not the right direction.

I know the direct manipulation paradigm is very important but please do note my comments in the PR description as to why I felt it was worth exploring.

Very much appreciated.

[getdave]

With latest improvements in Nav I no longer feel this is required.

[getdave]

I'm happy to pick this up again if anyone feels it would be useful. Please ping me.

[dwolfe]

🖐️ I think it would be useful!

To elaborate, I think this is specifically a problem when adding a link, not necessarily editing. When you add a link, you click the inserter button, and focus immediately goes to the URL field. The placeholder/hint for the link text is greyed out, which is what it's supposed to look like, ie. that's a good thing, but I think there's a slight mental jump to direct your attention back up to where you clicked, and realize that that's where you enter the link text.

I don't think editing has the same problem, because you click the link text itself to select the menu item, and the I-bar lets you know that you can edit that text. But for adding a link, I think the explicit field is more clear. Worth noting that Google Docs only has the additional field when you first add a link, as well.

Here's a quick GIF (there are a few other design tweaks here - you can ignore those, I'm merely trying to illustrate the addition of the "Link text" field):