allowedBlock attribute implementation at column

[JesserH]

Fixes #18161

Description

I have developed a solution to the issue where a individual column could not define any allowed blocks and newly added columns in the columns block (from the slider at the columns settings) also specify the allowed blocks.

How has this been tested?

I have tested this locally.

Screenshots

Types of changes

I have added a new attribute called allowedBlocks in both the column and columns block, which allows for defining the allowed blocks per individual column.
I suggest to add documentation to the InnerBlocks ReadMe on GitHub, where the templates are documented about the use of allowedBlocks.

EXAMPLE
You can set this property in for instance a template. Below is an example of how you can provide it to the column and columns block like so:

const allowedBlocks = [
  "cgb/recipe-name-block",
  "cgb/recipe-description-block",
  "cgb/recipe-author-block",
  "cgb/recipe-cuisine-block",
  "cgb/recipe-course-block"
];

//the code below can be used in a template
[ [ 'core/columns', { allowedBlocks }, [
      [ 'core/column', { allowedBlocks }, [
          [ 'cgb/recipe-name-block', { name: attributes.name, allowedBlocks },  ],
      ] ],
      [ 'core/column', { allowedBlocks }, [
        [ 'cgb/recipe-description-block', { recipeDescription: attributes.description, allowedBlocks },  ],          
     ] ],
  ] ] ],

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[jorgefilipecosta]

Hi @JesserH,
Here we are trying to change a block option, e.g., allows blocks from the outside. So we are solving issue #7931 for a specific case.

The solution we are using here is the addition of attributes. We have cases following the same approach, e.g., the placeholder in paragraphs and headings.

This approach, although working well, is not ideal:

• attributes are expected to be important for the block output (save), which is not the case.
• We are also serializing these attributes relevant to edit taking DB space.
• It presents challenges for block maintainability e.g.: parent block (A) that uses nested columns is updated and changes the columns allowed blocks. On older instances of (A), the columns allowedBlocks continues to be the old one. Users may wonder why the block did not change after a plugin updated.

On #18161 I suggest as a possible solution to the problem having an options mechanism something similar to attributes but not serializable and controlled from templates (e.g., parent templates, CPT templates), or from the data module by dispatching actions. This solution is complex, and we would essentially expand the block API's.

On #17352, I used context as a way to pass options from a parent to a child. The child exposes a component that allows ancestor blocks to configure a set of options. This option has some limitations; it does not allow to set options from a CP or from non-ancestor blocks.

Although the solution here has some inconveniences, the other solutions are not perfect either, because of the complexity or because of limitations.

Personally, I don't have a strong preference for this or for the other two options I referred. I guess we just need a decision on the path to follow. @youknowriad, @gziolo, do you have any preference for one of the options?

[gziolo]

Personally, I don't have a strong preference for this or for the other two options I referred. I guess we just need a decision on the path to follow. @youknowriad, @gziolo, do you have any preference for one of the options?

I'm exploring how we could integrate Patterns API into blocks and Columns block in particular in #18283. This raises the question if the list of allowed blocks should be part of this proposal.

[JesserH]

@gziolo I think this PR could very well be part of #18283 since it contains a big update for the columns block. With an update like this, I think it could be a good opportunity to implement this PR. #18283 also contains updates for the experimental template, which this PR is tightly related to.

[gziolo]

I think this PR could very well be part of #18283 since it contains a big update for the columns block. With an update like this, I think it could be a good opportunity to implement this PR. #18283 also contains updates for the experimental template, which this PR is tightly related to.

It would be nice but I don't think it would speed up things because it makes everything more complex. Let's keep it focused and consider those two independently. Patterns API is considered experimental for a reason. We want to move fast and cover as much as possible because we call it final. Explorations like this one will make it only better.

[JesserH]

@jorgefilipecosta Is there any preference yet in the solutions you mentioned that I can assist with? I would love to see this PR merged because I think it can really help Gutenberg block development.

[JesserH]

Closing this since this is outdated and me and @aristath created a new and updated version of this PR