fix: Remove block alignment from paragraph block (fix #6476)

[tofumatt]

Description

Remove the block alignment control for the paragraph block. This was requested in #6476.

How has this been tested?

Ran locally on Firefox/Chrome thus far. This is my first PR and there didn't seem to be unit tests around this file I could find, so I suspect I need to edit e2e tests.

Screenshots

Before

After

Types of changes

Removes the block alignment from the paragraph block completely. Simplifies alignment for the block but means it must rely on a container block for layout.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[tofumatt]

I had a look at testing the InspectorControls (writing a test that checked for the component I removed, and then making sure it failed when removed, and just generally adding test coverage for that section of the component), but it looks like this isn't done elsewhere and I didn't want a simple change to become a rabbit hole.

I would like to find a way to test the inspector controls, but I figured for now this is still getting rid of the confusing layout control as requested in the issue, so ready for review 😄

[youknowriad]

I would like to find a way to test the inspector controls, but I figured for now this is still getting rid of the confusing layout control as requested in the issue, so ready for review

I guess I'd personally do it by calling directly the edit property of the block and by adding the "InspectorControls" slot in the wrapping test component. But yeah, let's try this separately.

👍

[youknowriad]

LGTM 👍

[gziolo]

I think we should remove the block alignment toolbar from paragraphs altogether, as I feel like these should be reserved for a container block. So you select the container to choose the layout, and you can then choose individual paragraphs inside to change the text alignment.

@jasmussen, what about full and wide alignments for Paragraph block? Do you really think that using Columns container that is 2 columns by default is the way to go? Also what about all those old blocks that opted-in for any kind of alignment?

[jasmussen]

Yes, per some discussion in #6473 (comment), I think we should remove the block alignments from the paragraph. It made sense back when we had a "Cover Text" block, and it might make sense for other blocks. But the interface is not ideal, and it is especially confusing to have two types of alignments on the same block.

The Blockquote with nested paragraphs possibly can help define a path forward. The block alignment can be applied to the block quote itself, and text alignments can be applied to children. How we deal with paragraphs that need the same type of block alignments is a worthy challenge, though, but probably needs a different solution.

[gziolo]

I would like to find a way to test the inspector controls, but I figured for now this is still getting rid of the confusing layout control as requested in the issue, so ready for review

I guess I'd personally do it by calling directly the edit property of the block and by adding the "InspectorControls" slot in the wrapping test component. But yeah, let's try this separately.

It falls under integration tests category. It's very complex to setup because we use Slot & Fill approach which allows to render those controls in a different DOM tree but the same Virtual DOM tree :) As you noticed we don't test edit functions very in-depth, but only do shallow rendering with isSelected prop set to false (which reflects when a block isn't being edited) which by design doesn't render any toolbars and thus controls ... 😃

[gziolo]

@youknowriad, should width attribute be also removed from attributes and included only in the list of those deprecated. The same applies to the usage in save method?

[jasmussen]

CC: @mtias

[youknowriad]

@gziolo no, I noticed this too but thought we should keep it to avoid breaking existing paragraph. We don't have container blocks yet (section).

Though maybe we should add a comment next to the attribute definition

[gziolo]

My only concern is what will happen if someone set paragraph as aligned left or full and they won't be able to change that anymore. Maybe we should be more aggressive and reset it?

[jasmussen]

My only concern is what will happen if someone set paragraph as aligned left or full and they won't be able to change that anymore.

Wouldn't that invalidate the block and add the button to convert to blocks?

[gziolo]

Wouldn't that invalidate the block and add the button to convert to blocks?

This PR removes only the control, everything else is still there, so it won't invalidate the block.

[jasmussen]

I think that's fine. Users can edit the HTML here.

In general, I think we shouldn't be too scared of removing features, if we feel they add confusion or complexity, especially in this beta phase.

[gziolo]

@tofumatt, can you leave a code comment next to width definition that it should be moved to the deprecated list at some point, in here: https://github.com/WordPress/gutenberg/blob/master/core-blocks/paragraph/index.js#L300 before we merge?

[tofumatt]

I can move it to the deprecated list right now if that makes sense, but otherwise I can leave the comment.

[gziolo]

As discussed, let's see if it is easy to add deprecation. If that is too much hassle, let's leave a comment and move on to other things :)

[tofumatt]

I (think) I added deprecation properly and I tested it with blocks that had the old alignment set–they continued to save/load/work.

If I could get another set of eyes on it to make sure I did it right that'd be great, and if it's a pain I'll just add the TODO for now.

I seem to have needed to keep the width in the schema or it would just clear out the prop, so I'm not quite sure how the deprecation works if the schema needs to remain. I guess it's largely around saving old ways if they are set that way?

[youknowriad]

I'm not sure I understand why these were extracted, from my point of view the custom* attributes should remain in the schema because they are still being used. The width attribute should not though and should only be added to the deprecated version's attributes.

[tofumatt]

Arg, I thought these were deprecated attributes that are used only in deprecated versions of save… did I mix them up? I guess so.

When I removed width from the schema I got errors. I think deprecation is unclear to me.

[tofumatt]

Okay I think I did the deprecation right now, it's good for another look.

[tofumatt]

I got the thumbs-up for the deprecation from @youknowriad on Slack, so gonna merge this. 😄