Jetpack Blocks: Add the jetpack contact form blocks to the preset

[enejb]

Changes proposed in this Pull Request

• Add the contact form presets previously missing.

Testing instructions

• Build this PR in Jetpack and .com does things work as expected?
• Are you able to load create the contact form as expected?

We missed this in the previous release and allowed all the blocks to be loaded as they were.

[matticbot]

Test live: https://calypso.live/?branch=update/jetpack-preset-block.json

[simison]

How can I observe the brokeness without this change? :-)

[ockham]

Wondering the same as @simison 🙂 Personally, I guess I'd rather avoid having to include child blocks explicitly in a lot of places...

Also noting that this PR might impact #29134...

[enejb]

@simison I want to make the following change to jetpack Automattic/jetpack#10844

Without it this PR will not work as expected.

[ockham]

I"m all for de-duplicating information, but TBH, adding all those child blocks to index.json clutters it up quite a bit. I'd love if we could just rely on the parent block (i.e. Contact Form) to pull in its children as needed...

[tyxla]

I agree with @ockham and @simison, and I'm wonderijng - what's the value of specifically declaring all the child blocks in index.json?

[gititon]

I agree that if the presence of the parent block necessarily means that its child blocks are also included, index.json is much tidier when only the parent block is listed.

[enejb]

@tyxla, @gititon, @simison and @ockham.
There is no such thing as child blocks. As far as I know. The reason why I think we should have the complete list of blocks available in index.js is because it simplifies how we reason about things. If the item is in this list then the block is something that is available. There is no secondary list. That also influences things. At least we can make that happen for the beta blocks an wpcom proxied. Right now how things work is a bit of a mess.

The only reason why things work now is because we merge the current default blocks with the list in the index. The list of default blocks is hard coded in the Jetpack Gutenberg class.

Here is the PR that cleans it up on jetpack. Automattic/jetpack#10844

[tyxla]

There is no such thing as child blocks.

How come? Gutenberg has the concept of nested blocks AKA inner blocks, AKA child blocks - blocks that can only be inserted as nested blocks inside a limited set of parent blocks. Regardless of how we call them, it is a concept that exists in Gutenberg core, and we use it as well.

I don't see how that is a mess. I think that any block should be able to register child blocks, and block availability wouldn't have to know about them. That would change only in the event where we need to hide certain nested blocks for reasons (pain plans, etc.), and I don't see such a use case yet.

Personally, I think treating the nested blocks as regular blocks makes things more messy.

[enejb]

How come? Gutenberg has the concept of nested blocks AKA inner blocks, AKA child blocks - blocks that can only be inserted as nested blocks inside a limited set of parent blocks. Regardless of how we call them, it is a concept that exists in Gutenberg core, and we use it as well.

Yes there are such concepts as inner blocks but the inner blocks could have more then one parent. In gutenberg inner blocks define who the parent is and not the other way around. In someways it would make more sense to not include the form block because we could conditionally include it because a inner block knows about it. (I am not arguing for this just want to clarify things)

InnerBlocks still need to be register individually. If we only had to register the parent block to get the inner blocks I think what we currently have would make sense.

We are trying to separate the block definitions from when we register them. So having some block in the index and not the other ones doesn't make sense to me. The list is not complete.

The only reason why things work now is because of a bug. That I am trying to get rid of on the jetpack side. See Automattic/jetpack#10844

For example if I am working on an inner block that I want to beta tests before I release. How do we do that right now?

[gititon]

I've come around and agree with Enej that each block should be listed explicitly. This would ensure that there is a single source of truth for the blocks that are included, as opposed to some blocks being loaded by index.json and others being included as part of the Jetpack default blocks. As Enej explained to me, this would also facilitate beta testing inner blocks before they are added to production.

That said, I propose we indent the "child blocks" beneath the Contact Form block. While the whitespace will be inert, it will clearly distinguish these blocks as being child blocks of the Contact Form block as opposed to being "top level" blocks. This would make block inclusions explicit while at the same time keeping the list looking organized. E.g.,

{
  "production": [
    "contact-form",
        "field-text",
        "field-name",
        "field-email",
        "field-url",
        "field-date",
        "field-telephone",
        "field-textarea",
        "field-checkbox",
        "field-checkbox-multiple",
        "field-radio",
        "field-select",
    "map",
    "markdown",
    "publicize",
    "simple-payments"
  ],
  "beta": [
    "related-posts",
    "tiled-gallery",
    "vr"
  ]
}

[tyxla]

I've come around and agree with Enej that each block should be listed explicitly. This would ensure that there is a single source of truth for the blocks that are included, as opposed to some blocks being loaded by index.json and others being included as part of the Jetpack default blocks.

I'd prefer to go YAGNI with this. Do we have a real use case where this would be useful?

As Enej explained to me, this would also facilitate beta testing inner blocks before they are added to production.

This is likely the only good reason I see that could justify the added complexity. I wonder if we could find a better way...

That said, I propose we indent the "child blocks" beneath the Contact Form block.

What if a block can be a child block to multiple parent blocks?

[sirreal]

I'm closing because I believe this has been superseded by other work.

If that's not the case, please reopen.