Rich Text: Set applied format as active in applyFormats

[aduth]

Fixes #15503
Fixes #15522

This pull request seeks to resolve an issue where updates to links (and presumably any applied format?) may not immediately appear as having taken effect in the UI.

Implementation notes:

I'm not entirely comfortable in this realm of the code, but judging by some existing logic which modifies active formats in applyFormats for formats applied to collapsed text where the format was not already applied, I thought it might be safe to extrapolate this out to include the format as being considered active for any provided value. Alternative suggestions welcome.

Testing instructions:

Repeat Steps to Reproduce from #15503 and #15522, verifying expected results.

Ensure unit tests pass:

npm run test-unit packages/rich-text

[ellatrix]

I wonder if order could matter here. Could be not just copy the formats at the selection start? Or perhaps use getActiveFormats?

[aduth]

In my testing, it did matter: Where due to the behavior of normaliseFormats, the 'latest' format must occur first, since normaliseFormats defers to the previous entry:

gutenberg/packages/rich-text/src/normalise-formats.js

Lines 27 to 29 in 4108e37

	if ( isFormatEqual( format, previousFormat ) ) {
	newFormatsAtIndex[ formatIndex ] = previousFormat;
	}

I suppose I ought to document this more clearly.

[aduth]

Although looking closer at isFormatEqual, it's odd that it would have made any effective difference for me... considering that "latest" shouldn't matter if the attribute values (i.e. target="_blank" was not the same between formats anyways).

[aduth]

Although looking closer at isFormatEqual, it's odd that it would have made any effective difference for me... considering that "latest" shouldn't matter if the attribute values (i.e. target="_blank" was not the same between formats anyways).

I was looking at this wrong: activeFormats isn't considered for normaliseFormats. What I was seeing was explained by the fact that the active format was duplicated, and order mattered for how it was chosen for the UI. The changes in c8c5ed4 avoid duplication by ensuring that an equivalent format by type is first rejected.

I also found that removeFormats ought to be updated as well. This change was included in c4ebe80.

Generally I'm still a bit wary about how this all works, mostly because "active formats" seems like a UI concern which shouldn't be considered in this module. But given the precedent, this seems an improvement all the same.

Could be not just copy the formats at the selection start? Or perhaps use getActiveFormats?

I tried using getActiveFormats but it was problematic both because (a) it only considered formats at the start (not expected?) and (b) some difficulty around implementing the "placeholder" effect (I don't recall specifically if it was something of my own doing). Generating the activeFormats argument for this is essentially doing all the work already. In the end, I'm not really sure what purpose this function serves.

[youknowriad]

Anyone tested if this affects WP 5.2?

[ellatrix]

I'll have a closer look Monday.

[youknowriad]

In my testing, this is looking good.

[aduth]

d1843ee includes an updated end-to-end test which should verify regression fix against both #15503 and #15522 .

In scanning for other references to active formats within the rich-text module, I observe there are native equivalents to these files:

• https://github.com/WordPress/gutenberg/blob/master/packages/rich-text/src/apply-format.native.js
• https://github.com/WordPress/gutenberg/blob/master/packages/rich-text/src/remove-format.native.js

The changes in this pull request shouldn't introduce conflicts, though it is likely that if the logic was meant to align, the revisions here would not be reflected. I don't personally understand well enough why these files exist as native-specific to judge whether changes to those files are necessary (cc @koke , @hypest ).

[aduth]

I observe there is a utility function updateFormats which isn't used internal to the rich-text module itself, but could potentially prove a useful abstraction to normalizing how active formats are updated:

https://github.com/WordPress/gutenberg/blob/master/packages/rich-text/src/update-formats.js

This seems more as a general refactoring / consolidation point, however.

[koke]

The changes in this pull request shouldn't introduce conflicts, though it is likely that if the logic was meant to align, the revisions here would not be reflected. I don't personally understand well enough why these files exist as native-specific to judge whether changes to those files are necessary (

@Tug I don't remember why these were introduced, can you comment here?

[Tug]

We added those because we didn't want any regression in the editor compared to aztec (the mobile editor), especially regarding writing in multiple formats at once.

At the time gutenberg was not able to handle that properly so we "forked" the rich-text lib and hacked the formatPlaceholder prop to store the "active formats" information.

This is being removed in our fix PR which tries to bring in all the changes from #14640 into mobile.

[aduth]

Thanks @koke , @Tug . Since I'd not expect these changes to conflict with that effort, I'll operate on the assumption that I don't need to make any revisions to account for these files.