Links: do not reposition container on selection change

[ellatrix]

Description

Fixes #14872. It also makes sure that the container is positioned relative to the link element rather than the selection/caret, so it doesn't move when you move selection inside a link.

There are several steps that came to the fix.

1. I wanted to modify PositionedAtSelection so that it accepts a selector prop, to select the closest matching element to calculate the position from rather than the caret.
2. In order to not recreate PositionedAtSelection for every change in selection, we need to use the format object reference as an indicator to recreate, as each DOM element is a different object instance.
3. Unfortunately, React does not accept object references as keys, so we have to derive a simpler state to use as the key. I used getDerivedStateFromProps to bump the key every time the active format object changes.
4. Something was wrong in setting the activeFormats in onSelectionChange. The formats need to be taken from the current value to maintain references, not from the created value (from DOM) on the selection change.
5. To ensure object references persist in the RichText component across selection changes and edits, I've taken out recreating the rich text value for every change. This actually results in other positive changes: no more formatToValue call for every input event, and no more need memoize it, and no more need for updateFormats, introduced in RichText: unify active formats, 'selectedFormat' and 'placeholderFormat' #14411.

How has this been tested?

Screenshots

Types of changes

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.

[ellatrix]

The only remaining issue here is that the toolbar rerenders when you typing in the element. Fixing that now.

[aduth]

Possible dumb question: Couldn't a minimal solution just be to remove key (and make no other changes)?

[ellatrix]

What if you move the caret from one link to another?

[aduth]

What if you move the caret from one link to another?

That's true. I wonder then if it could either act more like the Autocomplete component in rendering Popover with a getAnchorRect that updates with the selection (but keeps the same element so not to unmount and re-trigger animation), or if PositionedAtSelection should update its styling in response to selection changes rather than once at mount. Both of these would still update the position on each selection change, but at least would avoid the repeated animations.

I'm not totally sure the ramifications of either of these alternatives. Just trying to consider in terms of the least potential for impact.

[aduth]

If we're working with a shallow clone, seems we might as well assign activeFormats directly, rather than create another shallow clone below?

const newValue = {
	...value,
	activeFormats: getActiveFormats( newValue ),
	start,
	end,
};

[aduth]

I don't understand why this change is here.

[ellatrix]

I'll comment, it's to make sure the boundaries work for annotations.

[ellatrix]

Updated the description:

To ensure object references persist in the RichText component across selection changes and edits, I've taken out recreating the rich text value for every change. This actually results in other positive changes: no more formatToValue call for every input event, and no more need memoize it, and no more need for updateFormats, introduced in #14411.

[ellatrix]

While I think we eventually want all the changes here to RichText, I'm going to make an alternative PR that doesn't touch as much existing code as it does now.

[aduth]

Needs to be rebased after #14938

[aduth]

(I'm assuming this doesn't need to land for Gutenberg 5.5 and have removed it from the milestone accordingly)

[ellatrix]

Closing for now.