Blocks: Add transform from Paragraph block to Cover Image block

[gziolo]

Description

I found it useful when copying the text from the external document. I wasn't able to convert a paragraph into a cover image directly. I had to transform the paragraph into a heading and finally into a cover image. I figured out it might simplify the flow if we provide also a direct transformation. I guess it might be not expected in some circumstances but I thought that it is still worth opening a PR since I need this code anyway to record a demo of Gutenberg :)

Screenshots (jpeg or gifs if applicable):

[jasmussen]

Thanks for making a PR.

I think this touches on a larger issue on transformations, and raises some good questions. Like, should we have the transformations both in the block toolbar dropdown or the ellipsis or just one of the two?

A more important question is: can we make rules for transformations that are more predictable?

I agree with the point of this PR that it's a bit weird that you can go Paragraph → Heading → Cover Image, and back the same route. I imagine the thinking behind it is that Cover Image is already a Heading, just with a background image, so you should be able to convert headings to Cover Images and vice versa. And if that is truly the thinking, then surely you should be allowed to go directly to Cover Image from paragraph too.

However I would argue that Cover Image, although technically a heading, is more of a decorative element, and that you should not be able to go from Heading to Cover Image. Moreover, going from Cover Image to Header is potentially destructive, in that you can lose the image in that conversion.

A more predictable conversion would be using multi-select: Paragraph | Heading & Image → Cover Image and vice versa, **Cover Image → Image & Paragraph **. Then at least the conversion would be non-destructive.

[mcsf]

I imagine the thinking behind it is that Cover Image is already a Heading, just with a background image, so you should be able to convert headings to Cover Images and vice versa.

In a nutshell, yeah (#4129).

A more predictable conversion would be using multi-select: Paragraph | Heading & Image → Cover Image and vice versa, Cover Image → Image & Paragraph. Then at least the conversion would be non-destructive.

I like that—seems like a concept worth trying out.

A couple of things on my mind for quite some time:

• Where do we draw the line before the user drowns in transform options?
• Can any of it be made smarter, more automated? This would include both: be smarter by not requiring devs to write so one-to-one transforms (possibly by inferring transforms from existing transforms or attribute schemata), and be smarter in what options the user should be shown.

[jasmussen]

Where do we draw the line before the user drowns in transform options?

Good question. Matías suggested a flyout menu. In either case I feel like either we have a strong pattern for transformations, so it's predictable what you can transform to. Multiple paragraphs to a list makes sense. Multiple images to a gallery makes sense.

CC @folletto as I recall we discussed transformations way back when.

Can any of it be made smarter, more automated? This would include both: be smarter by not requiring devs to write so one-to-one transforms (possibly by inferring transforms from existing transforms or attribute schemata), and be smarter in what options the user should be shown.

I would love it if that were possible.

I would love it if a plugin author could build a "Checklist Block", and simply register that this block was compatible with the "List" block, or multiple Paragraphs. But I suppose in this case we could never really prevent someone from registering their checklist block as compatible with "Cover Image"... Hmm.

[folletto]

Can any of it be made smarter, more automated? This would include both: be smarter by not requiring devs to write so one-to-one transforms (possibly by inferring transforms from existing transforms or attribute schemata), and be smarter in what options the user should be shown.

This would require me digging through how transformation happens right now, but I would expect something like:

• A block declares what data object needs as conversion input
• Any block that declares the same data object syntax as conversion output can export (which also means that a block can export multiple formats to be compatible with multiple blocks).

The idea of an approach like this is that any block provides the data for conversion in a forward way, so the burden is on the new block to provide the data to the existing block for conversion.

It would also take care implicitly (i.e. by implicit standardization) of compatibility: if a new block wants to be on the receiving end "like a checklist", they just have to accept the same syntax as a checklist, and so magically anyone that provides that format would be able to convert to it too.

It won't however take care of splitting a block in multiple blocks. This seems to me requiring a lot of explicit knowledge about blocks, and also would create some UI issues: "I asked to convert X yo Z, why have I ended up with Z... and Q?". I think destructive conversions are fine. That's why we have undo. :P

I'm less clear on how hard it would be to create such "data object" matching system.

[gziolo]

I'm closing this one as we didn't come up with the conclusion that it is expected behavior. I would rather prefer to continue with the idea shared by @folletto and provide a nice system for having a more standardized way of blocks transformation. It is probably something we should look into after the merge proposal happens. @karmatosed should we open an issue for that or put it on the nice to have list?