Infinite loops may occur when using useInnerBlocksProps from WordPress 5.7.

[ddryo]

After updating to version 5.7, custom blocks using __experimentalUseInnerBlocksProps now get the "Maximum update depth exceeded" error.

1. Error 1: It happens only when the block is inserted for the first time.
2. Error 2: It happens when you click on the border that spreads to the left and right of the block inserter.

These errors seems to occur only under some special conditions. I would like to report here the conditions that I have confirmed and how to avoid them.

How to reproduce the error

I have created a plugin that adds a block that meets the conditions that cause an error, so please use that.

▼ Plugin that can reproduce the error
https://github.com/ddryo/Error-Reproducer/tree/main/reproduce-use-innner-blocks-props-error

Get ready

1. Download the reproduce-use-innner-blocks-props-error folder from the link above.
2. Build the plugin with npm i and npm build.
3. Start WordPress with wp-env start.
4. Make sure the plugin "Reproduce use InnerBlocks Props error" is enabled.
5. Go to the post edit page and make sure you have two blocks for testing.

Error 1:

1. Adding a new "TEST-01" block.
2. Then the "Maximum update depth exceeded" error will occur.

But, saving the post and refreshing the screen will fix the problem.

For some reason, an error occurs only when inserting for the first time.

Error occurrence condition

1. The apiVersion is 2.
2. The block uses __experimentalUseInnerBlocksProps.
3. In addition, __experimentalUseInnerBlocksProps is used in its child blocks.
4. The template option is specified in the child block.
5. useSelect is used in the parent block, and the data of the inner blocks is acquired by select('core/block-editor').getBlocks().

How to avoid the error

1. Remove the template option from the child block.
2. The timing to get the data of the inner blocks is postponed until the necessary time comes.
   1. For example, get only the getBlocks() method with useSelect and execute getBlocks() inside the onChange process of the block controller.

Error 2:

1. Adding a new "TEST-02" block.
2. A block with two inner blocks will be inserted.
3. Click the border of the inserter that appears when you hover the mouse between blocks.
4. Then only the back block will crash. (If you don't get the error, try clicking a few times.)

Error occurrence condition

1. The apiVersion is 2.
2. The block uses __experimentalUseInnerBlocksProps.
3. In addition, __experimentalUseInnerBlocksProps is used in its child blocks.
4. The allowedBlocks option is specified in the child block, and specify the array directly in the allowedBlocks option.

How to avoid the error

• Specify allowedBlocks with a variable.

For example,

// NG
const innerBlocksProps = useInnerBlocksProps(blockProps, {
    allowedBlocks: ['core/paragraph', 'core/list'],
});

to

// OK
const innerBlocksProps = useInnerBlocksProps(blockProps, {
    allowedBlocks: ALLOWED_BLOCKS,
});

(Note: ALLOWED_BLOCKS is defined outside of registerBlockType().)

WordPress information

• WordPress version: 5.7.0
• Gutenberg version: "Not installed"
• Are all plugins except Gutenberg deactivated? "Yes"
• Are you using a default theme (e.g. Twenty Twenty-One)? "Yes"

Device information

• Device: Desktop
• Operating system: Mac OS Catalina
• Browser: Chrome

[torounit]

I tested the plugin and got the same error.

A large number of UPDATE_BLOCK_LIST_SETTINGS actions are generated.

[torounit]

@ddryo How about trunk ?
I think this is a problem that has been fixed in #30311

[talldan]

Thanks for reporting this @ddryo. This was also noticed on some core blocks and as @torounit mentions, has been fixed in #30311. That should be available in v10.4.

The problem is caused by a new array for allowedBlocks being created in every render, which the innerBlocks implementation wasn't optimized to handle.

If you'd like to fix the problem in your block before, you can make a similar change to the one here - https://github.com/WordPress/gutenberg/pull/30274/files

[ddryo]

@torounit @talldan

Oh! Thank you!
I'm sorry to report a resolved issue.

Will WordPress 5.7.1 fix this issue?