Skip to content

Commit

Permalink
Docs: Copy and formatting edits for the "The block wrapper" guide (#5…
Browse files Browse the repository at this point in the history
…8704)

* Initial edits.
* Additional copy and formatting edits.
* Fix typo

 Co-authored-by: ndiego <nick.diego@automattic.com>
Co-authored-by: justintadlock <greenshady@git.wordpress.org>
  • Loading branch information
ndiego committed Feb 7, 2024
1 parent bfac76c commit 073a798
Showing 1 changed file with 32 additions and 36 deletions.
68 changes: 32 additions & 36 deletions docs/getting-started/fundamentals/block-wrapper.md
Original file line number Diff line number Diff line change
@@ -1,37 +1,30 @@
# The block wrapper

Each block's markup is wrapped by a container HTML tag that needs to have the proper attributes to fully work in the Block Editor and to reflect the proper block's style settings when rendered in the Block Editor and the front end. As developers, we have full control over the block's markup, and WordPress provides the tools to add the attributes that need to exist on the wrapper to our block's markup.
Every block in the Block Editor is contained within an HTML wrapper, which must have specific attributes to function correctly both in the Editor and on the front end. As developers, we can directly manipulate this markup, and WordPress offers tools like `useBlockProps()` to modify the attributes added to a block's wrapper.

Ensuring proper attributes to the block wrapper is especially important when using custom styling or features like `supports`.
Ensuring proper attributes to the block wrapper is especially important when using custom styling or features like [block supports](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/).

<div class="callout callout-info">
The use of <code>supports</code> generates a set of properties that need to be manually added to the wrapping element of the block so they're properly stored as part of the block data.
</div>
A block in WordPress can be defined with three distinct types of markup, each serving a unique role:

A block can have three sets of markup defined, each one of them with a specific target and purpose:
- **Editor Markup:** This is the visual representation of the block within the Block Editor. It's defined using an `Edit` React component when the block is registered on the client side via [`registerBlockType`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#registerblocktype).
- **Save Markup:** This markup is what gets saved to the database when the block's content is saved. It's specified through a `save` function, also provided to `registerBlockType` during block registration. If the block doesn't utilize dynamic rendering, this saved markup is what will be displayed on the front end.
- **Dynamic Render Markup:** When a block's content needs to be generated dynamically, this markup comes into play. It's defined server-side, either through a `render_callback` function in [`register_block_type`](https://developer.wordpress.org/reference/functions/register_block_type/) or a [`render.php`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#render) file specified in `block.json`. If present, this markup overrides any saved markup and is used for the block's front-end display.

- The one for the **Block Editor**, defined through a `edit` React component passed to [`registerBlockType`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#registerblocktype) when registering the block in the client.
- The one used to **save the block in the DB**, defined through a `save` function passed to `registerBlockType` when registering the block in the client.
- This markup will be returned to the front end on request if no dynamic render has been defined for the block.
- The one used to **dynamically render the markup of the block** returned to the front end on request, defined through the `render_callback` on [`register_block_type`](https://developer.wordpress.org/reference/functions/register_block_type/) or the [`render`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#render) PHP file in `block.json`
- If defined, this server-side generated markup will be returned to the front end, ignoring the markup stored in DB.
For both the [`Edit` component and the `save` function](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/), it's important to use a wrapper element that's a standard DOM element (like a `<div>`) or a React component that passes all additional props to native DOM elements. Using React Fragments (`<Fragment>`) or the `<ServerSideRender>` component won't work for these wrappers.

For the [`edit` React component and the `save` function](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/), the block wrapper element should be a native DOM element (like `<div>`) or a React component that forwards any additional props to native DOM elements. Using a `<Fragment>` or `<ServerSideRender>` component, for instance, would be invalid.
## Editor markup

The [`useBlockProps()`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/#useblockprops) hook, provided by the [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor) package, is used to define the outer markup of a block in the `Edit` component.

## The Edit component's markup
This hook simplifies several tasks, including:

The [`useBlockProps()`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/#useblockprops) hook available on the [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor) allows passing the required attributes for the Block Editor to the `edit` block's outer wrapper.
- Assigning a unique `id` to the block's HTML structure.
- Adding various accessibility and `data-` attributes for enhanced functionality and information.
- Incorporating classes and inline styles that reflect the block's custom settings. By default, this includes:
- The `wp-block` class for general block styling.
- A block-specific class that combines the block's namespace and name, ensuring unique and targeted styling capabilities.

Among other things, the `useBlockProps()` hook takes care of including in this wrapper:

- An `id` for the block's markup
- Some accessibility and `data-` attributes
- Classes and inline styles reflecting custom settings, which include by default:
- The `wp-block` class
- A class that contains the name of the block with its namespace

For example, for the following piece of code of a block's registration in the client...
In the following example, the Editor markup of the block is defined in the `Edit` component using the `useBlockProps()` hook.

```js
const Edit = () => <p { ...useBlockProps() }>Hello World - Block Editor</p>;
Expand All @@ -40,9 +33,11 @@ registerBlockType( ..., {
edit: Edit
} );
```
_(see the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/minimal-block-ca6eda/src/index.js) in [an example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/minimal-block-ca6eda))_

...the markup of the block in the Block Editor could look like this:
_See the [full block example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/minimal-block-ca6eda) of the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/minimal-block-ca6eda/src/index.js)._

The markup of the block in the Block Editor could look like this, where the classes and attributes are applied automatically:

```html
<p
tabindex="0"
Expand All @@ -61,14 +56,15 @@ _(see the [code above](https://github.com/WordPress/block-development-examples/b
>Hello World - Block Editor</p>
```

Any additional classes and attributes for the `Edit` component of the block should be passed as an argument of `useBlockProps` (see [example](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/stylesheets-79a4c3/src/edit.js)). When you add `supports` for any feature, they get added to the object returned by the `useBlockProps` hook.
In a block's `Edit` component, use the `useBlockProps()` hook to include additional classes and attributes by passing them as arguments. (See [example](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/stylesheets-79a4c3/src/edit.js))

When you enable features using the `supports` property, any corresponding classes or attributes are included in the object returned by `useBlockProps` automatically.

## The Save component's markup
## Save markup

When saving the markup in the DB, it’s important to add the block props returned by `useBlockProps.save()` to the wrapper element of your block. `useBlockProps.save()` ensures that the block class name is rendered properly in addition to any HTML attribute injected by the block supports API.
When saving the markup in the database, it’s important to add the props returned by `useBlockProps.save()` to the wrapper element of your block. `useBlockProps.save()` ensures that the block class name is rendered correctly in addition to any HTML attributes injected by the block supports API.

For example, for the following piece of code of a block's registration in the client that defines the markup desired for the DB (and returned to the front end by default)...
Consider the following code that registers a block in the client. Notice how it defines the markup that should be used when editing the block and when the block is saved in the database.

```js
const Edit = () => <p { ...useBlockProps() }>Hello World - Block Editor</p>;
Expand All @@ -80,17 +76,17 @@ registerBlockType( ..., {
} );
```

_(see the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/minimal-block-ca6eda/src/index.js) in [an example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/minimal-block-ca6eda))_
_See the [full block example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/minimal-block-ca6eda) of the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/minimal-block-ca6eda/src/index.js)._

The markup of the block on the front end could look like this, where the class is applied automatically:

...the markup of the block in the front end could look like this:
```html
<p class="wp-block-block-development-examples-minimal-block-ca6eda">Hello World – Frontend</p>
```

Any additional classes and attributes for the `save` function of the block should be passed as an argument of `useBlockProps.save()` (see [example](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/stylesheets-79a4c3/src/save.js)).
If you want to add any additional classes or attributes to the `save` function of the block, they should be passed as an argument of `useBlockProps.save()`. (See [example](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/stylesheets-79a4c3/src/save.js))

When you add `supports` for any feature, the proper classes get added to the object returned by the `useBlockProps.save()` hook.
When you add `supports` for any feature, the proper classes get added to the object returned by the `useBlockProps.save()` hook. Text and background color classes have been added to the Paragraph block in the example below.

```html
<p class="
Expand All @@ -102,11 +98,11 @@ When you add `supports` for any feature, the proper classes get added to the obj
">Hello World</p>
```

_(check the [example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/block-supports-6aa4dd) that generated the HTML above in the front end)_
The [example block](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/block-supports-6aa4dd) that generated this HTML is available in the [Block Development Examples](https://github.com/WordPress/block-development-examples) repository.

## The server-side render markup
## Dynamic render markup

Any markup in the server-side render definition for the block can use the [`get_block_wrapper_attributes()`](https://developer.wordpress.org/reference/functions/get_block_wrapper_attributes/) function to generate the string of attributes required to reflect the block settings (see [example](https://github.com/WordPress/block-development-examples/blob/f68640f42d993f0866d1879f67c73910285ca114/plugins/block-dynamic-rendering-64756b/src/render.php#L11)).
In dynamic blocks, where the font-end markup is rendered server-side, you can utilize the [`get_block_wrapper_attributes()`](https://developer.wordpress.org/reference/functions/get_block_wrapper_attributes/) function to output the necessary classes and attributes just like you would use `useBlockProps.save()` in the `save` function. (See [example](https://github.com/WordPress/block-development-examples/blob/f68640f42d993f0866d1879f67c73910285ca114/plugins/block-dynamic-rendering-64756b/src/render.php#L11))

```php
<p <?php echo get_block_wrapper_attributes(); ?>>
Expand Down

1 comment on commit 073a798

@github-actions
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flaky tests detected in 073a798.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7821138934
📝 Reported issues:

Please sign in to comment.