Allow developers to reuse default blocks in their blocks

[lumberman]

I'm coding new custom blocks. For every custom block, I have to copy paste whole files of code to get the same functionality you already have in the default blocks. It's very confusing and goes against "do not repeat yourself" principle we try to stick to.

Issue:

For example, if I need to create a new custom block "Recipe" with the next structure:

• Image (a dish image)
• Heading (recipe name)
• Text block (description)
• List (ingredients)
• Button (call to action)

I will have to copy/paste the code from 5 already coded default blocks. What even worse: I will have to monitor official blocks for further improvements/changes in the future and update my block accordingly.

Please, allow 3-rd party developers to easily reuse already coded default blocks in their blocks.

Something like <Freeform /> <Image /> <Button /> <Heading /> <Paragraph /> will make our lives much easier.

Benefits:

• Good for the end users: they don't have to learn custom variations of the same content types like an image, button, etc..
• Good for 3-rd party developers: easy to create complex blocks
• Good for Gutenberg developers: less code from 3-rd party developers means fewer issues/errors for the whole product
• Good for the project: standardization, consistent design, and usage patterns

It's better to do this now, not after release as many 3-rd party developers with have to create custom blocks for their plugins before Gutenberg merged into WP.

I see no reason why it can't be good for everyone.

[youknowriad]

We're thinking of a "template" feature for CPTs which is a list of prefilled blocks. I can't seem to find the corresponding ticket but the idea is that a CPT defines a template with mandatory locked blocks.

I think this would address most of the concerns here.

[mtias]

Also nested blocks would allow to define a <BlockList blocks={ [ 'image', 'heading' ] } userEditable={ false } /> within a custom block.

[lumberman]

@youknowriad I don't think CPT is something similar to what I'm building. I definitely don't want to "pollute" users WP admin/DB with extra CPTs for cases when they use a custom block only a few times on a whole website. It will be great if you direct to the ticket. Maybe I'm wrong.

@mtias thanks for this inside. The problem that we know nothing about planned features. There is no roadmap that we can see. This way we waste too much of time on development of the stuff that we will have to redo completely later (on another side we can't wait and release it long after Gutenberg merged). <BlockList />, for example, will completely solve my problems, but there is no way to tell when this feature will be added. By any chance, you/other lead developers can take 1 hour off to put your vision into one single post or GitHub issue? That will help a lot. Thank you!

[munirkamal]

This is a really great suggestion. This will definitely make the 3rd party developer's life much much easier and will ultimately bring improved code overall to 3rd party plugins, as they will be mostly referencing already available core blocks (in many cases).

Just for a practical reference, I would like to point SiteOrigin's Widget API here. Their API brings widgets (like blocks in Gutenberg) as a field type simply. So if a 3rd party developer building a site origin widget and needs a button, he/she doesn't need to code the button component but can just include the core (SiteOrigin) button. Here is the specific field type reference.
https://siteorigin.com/docs/widgets-bundle/form-building/form-fields/#heading-widget

I am not sure if this will be a helpful reference here, but I am just dropping in case it is.

[gziolo]

This should be possible once nested blocks are merged into Gutenberg. Related PR #3745. Well technically it will be possible. @aduth or @mtias, have do you see all the building blocks (nested blocks, templates) playing together in this context?

[aduth]

The changes proposed in #3745 were modeled with this in mind; while not currently implemented, it should be fairly simple to extend InnerBlocks with a default set of blocks, editable or not (like in #2995 (comment)), and also which blocks are/aren't permitted in the nesting context.

[munirkamal]

@aduth Great to hear that. This will be really helpfull\ and will make the life much easier for 3rd party developers.

[maharzan]

Has this been implemented yet? For example, I am trying to reuse the Gallery block functionality but just have different settings and styling with an option to also have the default galleries.

[mtias]

For your use case, it seems block variations could be what you are after: https://developer.wordpress.org/block-editor/developers/block-api/block-registration/#variations-optional and https://richtabor.com/block-variations/