Defining block controls in block.json

[ryanwelcher]

When creating a custom block, extenders must define any custom controls in the Edit component by wrapping them in one of the components that target the various locations where controls can be displayed i.e <InspectorControls /> ,<BlockControls />, and others.

Example

const Edit = ( { attributes, setAttributes } ) => {
	const { setting } = attributes;
	return (
		<div { ...useBlockProps() }>
			<p>All of the block markup seen in the block editor goes here.</p>
			<InspectorControls>
				<TextControl
					label={ __( 'My Setting' ) }
					value={ setting }
					onChange={ ( newValue ) =>
						setAttributes( { setting: newValue } )
					}
				/>
			</InspectorControls>
		</div>
	);
};

Why?

This can be a confusing experience as the main purpose of the Edit component is to represent how the block displays when being edited in the block editor and adding the additional components to wrap controls that are seen in different locations seems like "magic". Additionally, in my experience, adding mosts controls are more of a copy/pasting boilerplate code process than doing anything custom.

I'd like to start a discussion around moving the definition of these controls to the supports property of block.json. This would be inline with the current paradigm of using block supports to enable settings for color, typography, spacing, etc and would also allow defining simple controls very quickly.

More advanced controls could also be defined and used in this same manner by providing a file: reference to the file that contains the exported component. This is also an existing paradigm that is used in block.json for properties such as viewScript, editorScript and others.

As the block API progresses, having an approach like this to separate the markup for the block editor and the controls for the block would mean that in theory, the API would be able to safely to affect the Edit component dynamically without losing the defined controls. This becomes important and necessary if we are ever to try generating the markup dynamically in order to try to keep markup consistent between Edit and render.php with some kind of automated process.

Having the controls defined block.json also provides the ability to modify them via the various block filters which opens up many opportunities for extenders to add or remove controls both core and third-party blocks as needed.

We would need to maintain backwards compatibility and keep the current way of adding controls in place .

Potential implementation

To demonstrate, I would like to propose a new property, let's call it controls that would accept an array of objects.

The possible properties for these object would be:

• type - the type of control. This would map to a component or couold have the value of custom
• location - where this control is rendered. i.e InspectorControls, BlockToolbar etc
• label - the label for the control to display
• attribute - the name of the attribute that will store the value of the setting
• component - the path to the custom component to be rendered when type is set to custom

"supports": {
	"controls" : [
		{
			"type": "text",
			"location": "inspector",
			"label": "My Setting",
			"attribute" : "setting"
		},
		{
			"type": "custom",
			"component": "file:../my-custom-control.js"
		}
	]
},

This implementation is a first thought on how this could work and is only intended to spark conversation.

@Mamaduka pinging you here as this seems related to your work on #51005