feature: Add ability for themes to configure font sizes; Extract fontSize logic from paragraph

[jorgefilipecosta]

This PR depends on #6618.
It extracts the logic to manage font sizes in a similar way to what we used to abstract the color logic.
We refactored the styles, so they are not specific to paragraphs. Now, other blocks can make use of the same classes.
The class names were renamed from the format is-large-text to has-large-font-size, this makes the names consistent with the names used in color classes. The new name makes clear that the primary style set is the font-size.
Color sizes are now read from editor settings instead of being a constant in the paragraph block.

Themes can now configure the font sizes show in the editor.
Fixes: #5714

How has this been tested?

Verify changing font sizes in the paragraph still works as before, no noticeable changes are expected.
Verify we are back compatible with blocks using the old class names by pasting the following text in the code view:

<!-- wp:paragraph {"fontSize":"large"} -->
<p class="is-large-text">test</p>
<!-- /wp:paragraph -->

Add the follwing code to a theme functions.php and verify that the size picker correctly reflects it:

add_theme_support( 'editor-font-sizes', array(
    array(
        'name' => __( 'extra small', 'themeLangDomain' ),
        'shortName' => __( 'XS', 'themeLangDomain' ),
		'size' => 8,
		'slug' => 'extra-small'
    ),
    array(
        'name' => __( 'small', 'themeLangDomain' ),
        'shortName' => __( 'S', 'themeLangDomain' ),
		'size' => 12,
		'slug' => 'small'
    ),
    array(
        'name' => __( 'regular', 'themeLangDomain' ),
        'shortName' => __( 'M', 'themeLangDomain' ),
		'size' => 16,
		'slug' => 'regular'
    ),
    array(
        'name' => __( 'large', 'themeLangDomain' ),
        'shortName' => __( 'L', 'themeLangDomain' ),
		'size' => 36,
		'slug' => 'large'
    )
) );

Use Highlight Updates dev tools feature to verify no unnecessary re-renders happen when comparing to master.

[aduth]

This has merge conflicts which need to be resolved. I'll review what's here in the meantime.

[aduth]

Should this be built-in to the abstraction if "large" text (for accessibility compliancy) is a standard condition?

[jorgefilipecosta]

Yes maybe we can add a property of fontSize to contrast checker where we only pass the fontSize and it decides if it is large or not, but as it is not directly related to changes here I will do that in a different PR.

[aduth]

but as it is not directly related to changes here I will do that in a different PR.

Can you create a (ideally self-assigned) issue tracking this?

[jorgefilipecosta]

For this cases where I feel a PR would be very small, I prefer to create a PR directly instead of writing an issue. The PR is available at #8059.

It ended up being a little bigger than what I was expecting initally because I needed to add additional test cases.

[aduth]

My initial reaction without looking through to see the implementation: Why do we have both fontSize.class and getFontSizeClass?

[jorgefilipecosta]

We use fontSize.class on the edit method because there it was already computed by the HOC. On the save function we don't use the HOC so we use the getFontSizeClass.

[aduth]

Seems unnecessarily disjointed.

[jorgefilipecosta]

The alternatives are:
- not passing class in the HOC and use getFontSizeClass in the edit method (when editing we know class is going to be required so not passing it already is just adding more work to the developers).
- -try to use the HOC in the save (it seems unnecessary as most of its functionality is not used).- Edited: I think this is not an option because the HOC requires context and setAttributes which we don't have on save.

It seems the current version is better than the alternative we have it is also the same that we are doing in the colors logic so a change in this mechanism will require an update to the existing color mechanism so we keep the consistency.

[aduth]

For what reason are we changing the class syntax now?

• Do we need to update deprecated reference to the old syntax?
• There are still references to is-small-text, etc. in core-blocks/paragraph/style.scss

[jorgefilipecosta]

I feel using has-large-font-size is more inline with the classes we use for colors, and I would like to change theme.

Block with the old syntax are automatically migrated as classes differences are ignored during validation.

We are keeping the old classes, to not break the existing paragraphs on the front end. I think the solution here is adding a global deprecation notice and keep the classes for two versions and I updated the code to include the notice.

[aduth]

When would it ever not be font-size? Does this even need to be an option?

[jorgefilipecosta]

I would like to keep doors open, and maybe in the future we have a different kind of classes that need a different context e.g: relative-font-size. But its a fact that right now we don't use context at all so I will remove it for now in the future we can add it if needed.

[aduth]

What are we assigning here? I've no idea on a glance of the code.

[chrisvanpatten]

add_theme_support('editor-color-palette') was refactored in #7619 to use a single array parameter instead of multiple parameters. Maybe the same could be done here for consistency?

[jorgefilipecosta]

Hi @aduth thank you a lot for your review. I think I addressed most points. The remaining is the usage of getFontSizeClass in save vs fontSize.class in edit. The only solution I see is removing the class from fontSize and using getFontSizeClass in edit too. As it takes more effort from the developer I personally prefer the current approach, but the difference is not huge and if you prefer to use getFontSizeClass in both places I will gladly change the code.

Hi @chrisvanpatten the code and its documentation already used an array for fontSizes I missed the update on the PR description it is now corrected.

[chrisvanpatten]

@jorgefilipecosta Awesome, looks great :) Excited for this!

[gziolo]

I left a few comments. I have some concerns regarding the current implementation of withFontSizes HOC. At first glance it seems like we are introducig additional logic which needs happen on everyt attribute change.

[gziolo]

Nit: It should be reworderd to

ending with -font-size.

[gziolo]

It's 3.6 now.

[gziolo]

Why not extra-large? Similar to the example where we have extra-small.

[jorgefilipecosta]

Hi @gziolo these names were chosen when configurable font named sizes were added in #5269. Changing them requires a complex deprecation logic and the gain with the change is not obvious. I updated the docs to use the same names so we are consistent.

[gziolo]

Can't do much about it 🤷‍♂️

[gziolo]

We have fontSizes provided in settings. Do we really need this default value?

https://github.com/WordPress/gutenberg/pull/6628/files#diff-6e3d39c654369a46e3c418427b3dbddbR9 - here we don't provide the default value. We should pick one approach.

[gziolo]

This method will be called every time any prop changes which means every time any attribute will change. Is there any way to opimize it to avoid doing all those computations where values change for attributes that have nothing to do with fonts?

[jorgefilipecosta]

Hi @gziolo, I optimized the performance of this function. And now in the most common case where props unrelated to font size change we just compare the font size props with the previous version. Of course, the code is now a little bit more complex because of this optimization.

[gziolo]

It should return null when no changes happened. See: https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#new-lifecycle-getderivedstatefromprops.

[gziolo]

The new static getDerivedStateFromProps lifecycle is invoked after a component is instantiated as well as before it is re-rendered. It can return an object to update state, or null to indicate that the new props do not require any state updates.

[jorgefilipecosta]

Corrected, I'm still mind programmed to return the same value when changes did not happen.

[gziolo]

It seems like you could further simplify this code using filter method;

const changedAttributes = filter( fontSizeAttributeNames, didAttributesChange );

if ( changedAttributes.length === 0 ) {
    return null;
}

const newState  = reduce( fontSizeAttributeNames, ( newStateAccumulator, customFontSizeAttributeName, fontSizeAttributeName ) => {
    // the same logic but without if statement
}, {} );

return {
    ...previousState,
    ...newState,
};

[jorgefilipecosta]

I did some code improvements following the logic you proposed. I was not able to use filter because filters always return an array but I used pickBy (is equivalent for the object case).
I kept the "some" verification, because creating a new object is still a non-trivial operation and doing the check allows us to on the most common case (font attributes did not change) do only comparisons.

[gziolo]

I tested it locally and everything works great. I ensured that there are no unnecessary rerenders when changing non-font attributes. Awesome job with this one.

Feel free to merge as soon as you address my last comment.

[gziolo]

compose and createHigherOrderComponent should be imported from @wordpress/compose - I see deprecation warning on the JS console.