Synced Patterns: Not receiving alignment attribute in editor

[brettsmason]

Describe the bug
I'm attempting to use the shared blocks feature but have hit an editor specific issue with alignfull and alignwide. When converting a a wide or full width block to shared, in the editor view the block looses its width. This does not apply to the front end which works fine.

To Reproduce

1. Create a block that supports full width/wide width (eg cover block).
2. Save the block as a shared block.
3. The block is no longer the width specified.

Expected behavior
I expected the shared block to keep the current data-align: full/wide that non-shared blocks receive when setting the alignment. This makes it very difficult currently to use shared blocks for aligned blocks, as its not an accurate representation of how the block actually looks.

Screenshots

[brandonpayton]

I am able to reproduce this.

[notnownikki]

Looks like getBlock in packages/editor/src/store/selectors.js doesn't apply the filters needed to add the extra props and attributes for features provided by the supports hooks. I'll see what I can figure out.

[notnownikki]

@youknowriad @noisysocks could I get a bit of feedback here? The reusable block is got with the originalContent but the features supplied by the supports hooks are only applied on save, so we'd have to use getSaveContent from the blocks serializer to make sure the reusable block has exactly the same output as the original block would have when it's saved shown in the editor. Does that sound like an acceptable solution?

[notnownikki]

oook, so that's not quite the problem. I'm still investigating, but it looks like when the block is rendered, the align isn't applied because it's taking the supports from the block block, instead of the cover block.

[notnownikki]

Yeah, that seems to be the problem.

When the filters are applied, they get core/block and because core/block constructs a BlockEdit element insides its render, it never gets exposed to the filters it needs for supports to work.

Not sure how to handle this one yet.

[jasmussen]

I can explain why this is happening. I don't know that we can get this fixed for 5.0, but perhaps we can for 5.0.1. But it's important to note — this is an issue isolated to the editor, the front-end view will still render correctly.

All blocks in the editor have a max-width, and are centered.

Blocks with align-wide have a wider max-width, and blocks with align-full have no max-width and therefore span the full width.

If you convert a wide image into a reusable block, it is now a wide image wrapped in a reusable block container. I.e. the image inside the container still has a wide alignment, but it is now constrained by the parent block, the reusable block container, which has the same max-width as any other normal block.

I can think of two ways to fix it:

1. Make all reusable blocks always be fullwide. Any blocks stored inside will retain their max-widths and be correctly centered. See:

2. Let the reusable block detect that a child block inside has a wide or fullwide block, and assign that attribute to the reusable block group itself. That way the reusable block will be wide when a child is wide, and fullwide when a child is wide.

2 is arguably the best user experience, but is probably also the most complex.

1 is relatively trivial to implement, but is arguably a little confusing. But it still might be the best way to do it. Assigning for some design feedback.

[notnownikki]

It's not specific to align either, any feature applied with the supports block attribute does not get applied to reusable blocks in the editor. So there's the design aspect, and having supports propagate to reusable blocks too.