templateLock={ false } breaks template in 5.2.1

[mattjbrent]

Describe the bug
A block was created similar to core/columns and core/column. Where the child block was set to templateLock={ false } and the parent block was set to templateLock='all'. It contained very similar functionality to core/columns. Moving a slider adds or removes a child column block.

However changing the templateLock on the parent to false breaks the template when adding or removing new columns. Increasing the number of columns does not add in the additional blocks via the template.

To reproduce
Steps to reproduce the behavior:

1. Duplicate a minimum viable block using core/column and core/columns as a guide.
2. Change templateLock to false on the column parent block in the edit file.
3. Save go out to the editor and add new columns, observe no new templated column blocks are being added

Expected behavior
Regardless of the templateLock setting, blocks added through templates should remain unchanged.

Screenshots
The block hierarchy with templateLock="all"

The same code, changing templateLock={ false }

These are slightly modified but error is reproducible using fresh install of 5.2.1 and creating minimum viable block

Additional context

• Gutenberg V5.2.1 in Chrome 74
• To report a security issue, please visit the WordPress HackerOne program: https://hackerone.com/wordpress.

[jorgefilipecosta]

Hi @mattjbrent, thank you for reporting this issue.

Templates were implemented as a mechanism to prefill an InnerBlocks area with some pre-created blocks, in a similar way to what we had with CPT templates.
The template is applied when an InnerBlock area is empty, changing the template does not change the InnerBlocks inside the area unless the area is empty or we have templateLock all.
When the template lock is not all e.g: is false or insert, we don't know if the difference between the template and the current inner block area state is because the user explicitly changed the area, and doing a synchronization, in that case, may end up destroying content.

In the last version of Gutenberg when there is a change in the number of columns the update to the InnerBlocks happens because the columns block dispatches an action to replace its InnerBlocks:
const { replaceInnerBlocks } = dispatch( 'core/block-editor' );.

In the previous version of the columns block before resizing functionality was added, when the number of columns changed the template was updated but the synchronization only happened because columns contains a templateLock all.

So in order to fix the problem, you are facing I guess the best way is using a template lock all, so when the template changes a synchronization happens (you may then use child blocks inside without any locking), or you can explicitly call an action replaceInnerBlocks to change the InnerBlocks of your block when something happens (like an input is changed). Columns now follows the second approach:
https://github.com/WordPress/gutenberg//blob/855be7927f31cf89229e954829e78e23d6a871e8/packages/block-library/src/columns/edit.js#L215

I hope you find this explanation clear if I missed something or you need additional information feel free to comment/reopen the issue so we can look further into this issue.

[mattjbrent]

@jorgefilipecosta thanks for your detailed reply. I solved this by also using replaceInnerBlocks and dealing with it more granularly. I'm also finding using the various exposed APIs reasonably sane to work with (although in some cases documentation is sparse and not particularly detailed)

Are there more detailed documentation pertaining to more advanced APIs like this - I feel like the documentation on the site is very approachable but lacks depth and some of the inline documentation is not the clearest. If there was clearer documentation - i probably wouldnt have needed to ask this question.

Thanks again for your time.

[jorgefilipecosta]

Hi @mattjbrent I'm glad you managed to fix the problem. More advanced data api's are documented in https://developer.wordpress.org/block-editor/data/. The specific action is documented at replaceInnerBlocks https://developer.wordpress.org/block-editor/data/data-core-block-editor/#replaceInnerBlocks.

[firxworx]

Hmmm... this looks to be the reason why insertBlock() was apparently silently failing (!) if I set templateLock to anything other than all in my parent block.

I'm working on an accordion-type block and found this behaviour to be completely unexpected and undocumented. I'm glad I finally noticed that templateLock was the culprit and that's what led me to this issue. Otherwise, of course I would think that my inner blocks (accordion expand/collapse items) should be removable and rearrangeable (templateLock={ false }). Honestly Gutenberg currently has one of the worst developer experiences of the entire React ecosystem... learning it's boundless nuances an absolute chore, as if everything to do with InnerBlocks wasn't bad enough.

(hopefully my rant helps inject a few more keywords to anyone trying to make an accordion, tab / tabs / tabbed, or similar type block ;) )

Thanks for submitting the bug @mattjbrent and MANY THANKS to @jorgefilipecosta for the detailed reply. Your valuable insights are hugely appreciated.

Interestingly when investigating my issue, I looked over the coblocks accordion implementation, which does NOT set templateLock to all on the parent element but it still works (you can delete accordion items within the parent block). At first glance it looks like it might have something to do with his use of transforms in index.js.
https://github.com/godaddy/coblocks/blob/master/src/blocks/accordion/components/edit.js#L113

Thanks again!