Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Add third block supports page to the create block tutorial of the framework docs. #56483

Merged
merged 3 commits into from
Nov 24, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 33 additions & 12 deletions platform-docs/docs/basic-concepts/settings.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,14 +6,43 @@ sidebar_position: 3

You can customize the block editor by providing a `settings` prop to the `BlockEditorProvider` component. This prop accepts an object with the following properties:

## __experimentalFeatures
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Two things here:

1- We need to stabilize this setting
2- I've noticed that by default, if we don't define this setting, the block editor doesn't support any of the default block supports (aside font size for some reason). I think that's not great and we should update the default value (or merge the prop with some sane defaults).

Copy link
Member

Choose a reason for hiding this comment

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

Even the label __experimentalFeatures is confusing - aren't these values (set here) merged theme.json settings derived from gutenberg_get_global_settings()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, I'm curious what would you call them?

Copy link
Member

Choose a reason for hiding this comment

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

Good question! This might sound naïve, but themeSettings 😃 🤷🏻

Copy link
Contributor

Choose a reason for hiding this comment

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

themeSettings makes sense after a quick glance at what's under __experimentalFeatures currently.

Would it be a little redundant having the Settings suffix for a property directly under settings, i.e. settings.themeSettings? I don't mind it, but don't have strong opinions here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's what's bothering me. we'd have settings.themeSettings, settings.styles and I know that we also want to introduce the "styles" part of theme.json, would that be settings.themeStyles (feels like the current styles are also themeStyles, just a different type).

I don't have solutions, but I think we need to look at this wholistically and keep in mind that block-editor package is not necessarily WordPress specific code. I think right now there's no concept of "theme" there.


The experimental features setting is an object that allows you to enable/disable common block editor features. For instance, the following settings enables support for text, background colors and allow users to pick a custom color or one of the defined theme palette colors. Core block types and third-party block types using the block supports feature will automatically take these settings into account.

```js
import { BlockEditorProvider, BlockCanvas } from '@wordpress/block-editor';

const features = {
color: {
custom: true,
text: true,
background: true,
palette: {
theme: [
{ name: 'red', color: '#f00', slug: 'red' },
{ name: 'white', color: '#fff', slug: 'white' },
{ name: 'blue', color: '#00f', slug: 'blue' },
],
},
},
};

export default function App() {
return (
<BlockEditorProvider settings={ { __experimentalFeatures: features } }>
<BlockCanvas />
</BlockEditorProvider>
);
}
```

## styles

The styles setting is an array of editor styles to enqueue in the iframe/canvas of the block editor. Each style is an object with a `css` property. Example:

```jsx
import { BlockEditorProvider, BlockCanvas } from '@wordpress/block-editor';

export const editorStyles = [
const styles = [
{
css: `
body {
Expand All @@ -36,14 +65,6 @@ export const editorStyles = [
`,
},
];

export default function App() {
return (
<BlockEditorProvider settings={ { styles: editorStyles } }>
Copy link
Contributor

Choose a reason for hiding this comment

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

Non blocking question: would it be worth still including the App example in these, so that it's clear that styles is a key of the settings object, rather than a direct prop on BlockEditorProvider?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, for now I kept it in the first setting and since I added a new initial setting, I moved it to the top. Open to reconsidering this, just leaving it for later.

<BlockCanvas />
</BlockEditorProvider>
);
}
```

## mediaUpload
Expand Down Expand Up @@ -91,7 +112,7 @@ Providing a `mediaUpload` function also enables drag and dropping files into the
The inserter media categories setting is an array of media categories to display in the inserter. Each category is an object with `name` and `labels` values, a `fetch` function and a few extra keys. Example:

```jsx
{
const inserterMediaCategories = {
name: 'openverse',
labels: {
name: 'Openverse',
Expand Down
24 changes: 12 additions & 12 deletions platform-docs/docs/create-block/attributes.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,29 +46,29 @@ registerBlockType( 'gutenpride/gutenpride-block', {
} );
```

## TextControl Component
## PlainText Component

For our example block, the component we are going to use is the **TextControl** component, which is similar to an HTML text input field. You can see [the documentation for the `TextControl` component](https://developer.wordpress.org/block-editor/reference-guides/components/text-control/). You can browse an [interactive set of components in this Storybook](https://wordpress.github.io/gutenberg/).
For our example block, the component we are going to use is the **PlainText** component, which allows the user to type some unformatted text. The **PlainText** component is imported from the `@wordpress/block-editor` package.

The component is added similar to an HTML tag, setting a label, the `value` is set to the `attributes.message` and the `onChange` function uses the `setAttributes` to update the message attribute value.
The component is added similar to an HTML tag, the `value` is set to the `attributes.message` and the `onChange` function uses the `setAttributes` to update the message attribute value.

The save function will simply write the `attributes.message` as a `div` tag since that is how we defined it to be parsed. Update the `edit.js` and `save.js` files to the following, replacing the existing functions.

**edit.js** file:

```js
import { useBlockProps } from '@wordpress/block-editor';
import { TextControl } from '@wordpress/components';
import { useBlockProps, PlainText } from '@wordpress/block-editor';

function Edit( { attributes, setAttributes } ) {
const blockProps = useBlockProps();
return (
<div { ...useBlockProps() }>
<TextControl
label="Message"
value={ attributes.message }
onChange={ ( val ) => setAttributes( { message: val } ) }
/>
</div>
<PlainText
{ ...blockProps }
tagName="div"
value={ attributes.message }
onChange={ ( val ) => setAttributes( { message: val } ) }
__experimentalVersion={ 2 }
/>
);
}
```
Expand Down
32 changes: 31 additions & 1 deletion platform-docs/docs/create-block/block-supports.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,33 @@
---
sidebar_position: 4
sidebar_position: 3
---

# Block Supports

A lot of blocks, including core blocks, offer similar customization options. Whether that is to change the background color, text color, or to add padding, margin customization options.

To avoid duplicating the same logic over and over in your blocks and to align the behavior of your block with core blocks, Gutenberg provides a list of reusable block supports.

Let's augment our Gutenberg pride block with some of these supports. To do so, we just update the `registerBlockType` call with an additional `supports` key like so:

```jsx
registerBlockType( 'gutenpride/gutenpride-block', {
// ...
supports: {
color: {
text: true,
background: true,
},
},
} );
```

If your block editor allows text and background colors, the block inspector will now show a panel that allows users to customize these colors for the selected block.

In addition to colors, the block editor provides by default a number of built-in block supports that any block type can use to quickly add customization options. These block supports include:

- colors
- typography
- borders
- dimensions and spacing
- and more...
2 changes: 1 addition & 1 deletion platform-docs/docs/create-block/nested-blocks.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
sidebar_position: 5
sidebar_position: 4
---

# Nested blocks
2 changes: 1 addition & 1 deletion platform-docs/docs/create-block/transforms.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
sidebar_position: 6
sidebar_position: 4
---

# Block Transforms
5 changes: 0 additions & 5 deletions platform-docs/docs/create-block/using-styles.md

This file was deleted.

2 changes: 1 addition & 1 deletion platform-docs/docs/create-block/writing-flow.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
sidebar_position: 7
sidebar_position: 6
---

# Writing Flow and Pasting
Loading