Add 'innerBlocks' support for transforms

[Luehrsen]

Description

This PR aims to provide support for 'innerBlocks' in transform rules. The proposed syntax is like this.

transforms: {
	from: [
		{
			type: 'block',
			blocks: ['agncy/split'],
			transform: function( attributes, innerBlocks ) {
                           return createBlock( 'wpm/split', attributes, innerBlocks );
                        },
		}
	]
},

How has this been tested?

This PR has been manually tested. E2E tests are possible and the needed plugin code exists, the test itself has not been written.

Types of changes

• Added an attribute to the transform function to regard innerBlocks
• Catched a possible error while rendering the block switcher where 'blocks' could be undefined due to a block not being registered

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

closes #13052

[Luehrsen]

I consider this PR more or less done from a code standpoint, as it is really minor.

However, I have not yet written (possible) e2e tests, as I have no idea how to do that. But I've updated the 'inner-blocks-templates' test plugin to add an appropriate block to test my two changes.

[jorgefilipecosta]

Nice changes @Luehrsen, thank you for your contribution 👍
Things tested well and the code looks good.
Given that we already have samples created here to be used in the tests, would it be possible to add a sample to https://github.com/WordPress/gutenberg/blob/master/docs/block-api.md#transforms-optional and document this enhancement to the API?

[jorgefilipecosta]

Nice changes @Luehrsen, thank you for your contribution 👍
Things tested well and the code looks good.
Given that we already have samples created here to be used in the tests, would it be possible to add a sample to https://github.com/WordPress/gutenberg/blob/master/docs/block-api.md#transforms-optional and document this enhancement to the API?

[Luehrsen]

@jorgefilipecosta Done.

While reviewing that doc-page: Aren't the ES5 examples wrong in terms of curly-braces and 'content' in reality being 'attributes'?

[aduth]

API-wise, this looks like a reasonable change which aligns with the general pattern of a "name, attributes, innerBlocks" triple when the name is already known.

Could you make the following changes?

• Additional unit tests for switchToBlockType in the test/factory.js file to cover new functionality
• A note in packages/blocks/CHANGELOG.md describing the new feature, bumping to a new minor "Unreleased" version (reference)

[aduth]

API-wise, this looks like a reasonable change which aligns with the general pattern of a "name, attributes, innerBlocks" triple when the name is already known.

Could you make the following changes?

• Additional unit tests for switchToBlockType in the test/factory.js file to cover new functionality
• A note in packages/blocks/CHANGELOG.md describing the new feature, bumping to a new minor "Unreleased" version (reference)

[Luehrsen]

@aduth I have updated the changelog as requested, but I am a total noob in terms of TDD, so any help with the unit test would be MUCH appreciated.

[aduth]

I rebased and force-pushed to resolve conflicts and add missing unit tests.

Writing the test for the multi-blocks, it became apparent that it's super goofy to pass as arguments two arrays of the attributes and innerBlocks of the blocks being transformed, rather than just the array of blocks themselves. Alas, it seems what we're forced into doing to keep backward-compatibility.

[aduth]

I rebased and force-pushed to resolve conflicts and add missing unit tests.

Writing the test for the multi-blocks, it became apparent that it's super goofy to pass as arguments two arrays of the attributes and innerBlocks of the blocks being transformed, rather than just the array of blocks themselves. Alas, it seems what we're forced into doing to keep backward-compatibility.