Block Library: Update Columns block to use Patterns API

[gziolo]

Description

Part 2 of #16283.

Fixes #18738.

Continuation of #18270. This branch is based on the add/patterns-api master branch.

This PR refactors Columns block to use this new API making the placeholder open for customization.

Selector

This PR also introduces a new selector which lets to find the default pattern:

/**
 * Returns the default block pattern for the given block type.
 * If there is no default pattern set, it returns the first item.
 *
 * @param {Object} state      Data state.
 * @param {string} blockName  Block type name.
 *
 * @return {?WPBlockPattern} The default block pattern.
 */
function __experimentalGetDefaultBlockPattern( state, blockName );

To ensure that icons have a shared size in the layout selection, this PR also adds a new prop to the IconButton component: size to make it possible to enforce one value for icons passed in various formats.

Components

__experimental BlockPatternPicker

I refactored an internal component InnerBlocksTemplatePicker from the InnerBlocks implementation. It's now called BlockPatternPicker and is exposed as an experimental feature __experimental BlockPatternPicker from @wordpress/block-editor package.

In addition, I slightly tweaked wordings in the UI to use the pattern keyword. It's also reflected in the name of props.

InnerBlocksTemplatePicker is no longer included in InnerBlocks as discussed in this PR. I updated all the corresponding documentation. This API was experimental so we don't need any further actions.

IconButton

I added a new size prop to IconButton component to make it possible to scale all icons to the same size in the block pattern picker.

How has this been tested?

npm run test-unit – new unit tests were added.

Columns block UI

1. Create a new post or open an existing one.
2. Add the Column block.
3. Click one of the layouts and double-check it was properly initialized.
4. Add another Column block.
5. Click the skip link and double-check that the default pattern was applied – 2 columns.

Extensibility

To add a new pattern to the Columns block:

wp.blocks.__experimentalRegisterBlockPattern( 'core/columns', { name: 'custom', label: 'Custom', isDefault: true, innerBlocks: [ [ 'core/column' ], [ 'core/column' ], [ 'core/column' ], [ 'core/column' ] ], icon: 'smiley' } ); 

To remove a pattern from the Columns block:

wp.blocks.__experimentalUnregisterBlockPattern( 'core/columns', 'two-columns-equal' ); 

When those two commands get executed, then the custom pattern becomes the default one. In effect, when you add a Column block and click the skip link, then 4 columns will be inserted.

IconButton

You can test in Storybook the IconButton and its new size prop. To do it run npm run design-system:dev and navigate to the proper page. You can use knobs to play with sizes:

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.

[gziolo]

@youknowriad, I applied some of the changes which were included in #18343. In particular, I added the wrapper for edit implementation which handles the process of the pattern selection automatically. This is the same approach as you could see in #18343 for Media & Text block which we decided to abandon because the UX wasn't good enough.

I really think we should build this as an implementation detail of BlockEdit (or other block editor components) from the start. Registering patterns for blocks, should be enough to tweak the behavior of the block (like styles, transforms)

This is very close to the vision shared. I'd like to refactor one more block to identify some potential issues with the current proposal. At the moment the wrapper which handles the pattern selection is presented when there are no nested blocks added to the block. In the case of Columns block, it's perfectly fine as it always needs to have at least 2 nested blocks. However, this might not fit all use cases as some blocks might assume that there might be no blocks provided when the block gets created. In addition, it doesn't cover also blocks that don't have inner blocks where we want to use Patterns API to offer some initial setup.

[youknowriad]

This is looking very good in my testing

[gziolo]

It looks like 13b6cae solves all the issues discussed. Icon component seems to work great. Let's see what Travis thinks.

[gziolo]

Nice, Travis likes the changes proposed. Thanks @youknowriad for the great tip 🥇

The only question remaining is whether we should remove TemplatePicker integration with InnerBlocks in this PR.

[youknowriad]

Using Icon in the IconButton can cause some breakage. Notably I see that DropIt icon is broken in the more menu, that said I'm fine if we can consider this a plugin issue but we should check quickly how many issues this could introduce.

[gziolo]

Using Icon in the IconButton can cause some breakage. Notably I see that DropIt icon is broken in the more menu, that said I'm fine if we can consider this a plugin issue but we should check quickly how many issues this could introduce.

I see why it can happen, it's the Inception issue 😄 Can we add the case in the Icon to merge props when it happens? I can give it a try.

[gziolo]

Using Icon in the IconButton can cause some breakage. Notably I see that DropIt icon is broken in the more menu, that said I'm fine if we can consider this a plugin issue but we should check quickly how many issues this could introduce.

I see why it can happen, it's the Inception issue 😄 Can we add the case in the Icon to merge props when it happens? I can give it a try.

It looks like the issue is different, there is size prop which gets overriden:

function Icon({ size = "small", borderless = false, color = "unsplash" }) {

https://github.com/youknowriad/dropit/blob/b0bd499ba85e9795fbb88199fff776123f60bdd5/scripts/sidebar/components/icon/index.js#L71-L83

[youknowriad]

yeah! I'm fine for this being a Dropit issue :)

[youknowriad]

LGTM 👍