Block library: Refactor Paragraph block to use class name for text align

[gziolo]

Description

Related: #16027, #15751, #16777, and #16779.

This PR follows-up #16035.

Before:

<!-- wp:core/paragraph {"align":"right"} -->
<p style="text-align:right;">... like this one, which is separate from the above and right aligned.</p>
<!-- /wp:core/paragraph -->

After:

<!-- wp:paragraph {"align":"right"} -->
<p class="has-text-align-right">... like this one, which is separate from the above and right aligned.</p>
<!-- /wp:paragraph -->

How has this been tested?

Using one of the existing branches (master probably) add a few Paragraph blocks and set different text alignments and save your post. Open the same post with this branch and ensure that it still works

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.

[gziolo]

When I go to Gutenberg demo page locally I see lots of warnings on JS console. It looks like validation runs twice, but more importantly in this case I need to update HTML source of the demo content. I plan to open a related PR where I will improve the feedback shared on the JS console. It clearly is wrong as is, we should only let developers know that post was properly converted and show what was before and how it is coded from now on.

@youknowriad, @aduth, @mtias or @mcsf, do you know why validation is triggered twice?

[aduth]

@gziolo If I had to guess without looking, we have a few issues present in development environments due to how React fires constructor twice in strict mode:

Strict mode can’t automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following methods:

• Class component constructor method
• [...]

https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

For us, likely most problematic here:

gutenberg/packages/editor/src/components/provider/index.js

Line 57 in f598210

props.setupEditor( props.post, props.initialEdits, props.settings.template );

[youknowriad]

Validation also runs for every deprecated version until it finds the "correct" version to use. I think the path forward would be to not show any error unless there's no corresponding deprecated version.

[gziolo]

@gziolo If I had to guess without looking, we have a few issues present in development environments due to how React fires constructor twice in strict mode:

Strict mode can’t automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following methods:

• Class component constructor method
• [...]

https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

For us, likely most problematic here:

gutenberg/packages/editor/src/components/provider/index.js

Line 57 in f598210

props.setupEditor( props.post, props.initialEdits, props.settings.template );

@aduth, you are totally correct. I tried with SCRIPT_DEBUG both enabled and disabled. I can see it triggered twice only in development mode which confirms what you shared. I guess we can ignore it then or refactor this provider to use hooks.

Validation also runs for every deprecated version until it finds the "correct" version to use. I think the path forward would be to not show any error unless there's no corresponding deprecated version.

@youknowriad – I'm working on it in separate PR 👍

[gziolo]

Applying Needs Dev Note as this might have an impact on themes which used the presence of style as a way to change the visual aspect of the block.

[youknowriad]

Any other block left with the inline styles for these?

[gziolo]

Any other block left with the inline styles for these?

It is the last one I think. Well, at least I don't have more PRs opened :)

We decided we don't add text-align to List block but it would be a new feature.