Skip to content
Merged
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
54 changes: 53 additions & 1 deletion packages/block-editor/README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Block Editor

Generic block editor module.
This module allows you to create and use standalone block editors.

## Installation

Expand All @@ -12,6 +12,58 @@ npm install @wordpress/block-editor --save

_This package assumes that your code will run in an **ES2015+** environment. If you're using an environment that has limited or no support for ES2015+ such as lower versions of IE then using [core-js](https://github.com/zloirock/core-js) or [@babel/polyfill](https://babeljs.io/docs/en/next/babel-polyfill) will add support for these methods. Learn more about it in [Babel docs](https://babeljs.io/docs/en/next/caveats)._

## Usage

```js
import {
BlockEditorProvider
BlockList
} from '@wordpress/block-editor';
import { useState } from '@wordpress/element';

function MyEditorComponent () {
const [ blocks, updateBlocks ] = useState( [] );

return (
<BlockEditorProvider
Copy link
Member

Choose a reason for hiding this comment

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

Any plans to introduce another wrapping component to make it as simple as:

return (
	<BlockEditor
		value={ blocks }
		onInput={ updateBlocks }
		onChange={ updateBlocks }
	>
		<BlockList />
	</BlockEditor
);

or something like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I ultimately think all these wrappers I'm using here should be part of BlockEditorProvider which is basically what you're proposing.

Copy link
Member

Choose a reason for hiding this comment

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

Awesome, I like where it is heading 👍

value={ blocks }
onInput={ updateBlocks }
onChange={ updateBlocks }
Copy link
Member

Choose a reason for hiding this comment

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

For someone who doesn't care about "Undo" levels, I wonder if the simplest example can just include onInput (or conversely, for one who cares only about important updates, only include onChange).

Though as I write this, I guess it assumes that onInput and onChange aren't mutually exclusive (i.e. onInput would always precede an onChange). I think this was an original intention, but by the final implementation it didn't end up this way:

if ( isPersistent ) {
onChange( blocks );
} else {
onInput( blocks );
}

The original thinking being that you could have onInput and onChange, or just individually one or the other of onInput or onChange.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good thoughts, and yeah I think you're right, it would have been better to have the two calls at the same time. I recall something related to the state making this harder for us but I think we can probably revisit specifically.

Copy link
Member

Choose a reason for hiding this comment

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

IIRC, #14105 was partly toward this goal as well.

>
<WritingFlow>
<ObserveTyping>
<BlockList />
</ObserveTyping>
</WritingFlow>
<Popover.Slot />
</BlockEditorProvider>
);
}

// Make sure to load the block editor stylesheets too
// import '@wordpress/components/build-style/style.css';
// import '@wordpress/block-editor/build-style/style.css';
```

In this example, we're instantiating a block editor. A block editor is composed by a `BlockEditorProvider` wrapper component where you passe the current array of blocks and on each change the `onInput` or `onChange` callbacks are called depending on whether the change is considered persistent or not.

Inside `BlockEditorProvider`, you can nest any of the available `@wordpress/block-editor` UI components to build the UI of your editor.

In the example above we're rendering the `BlockList` to show and edit the block list. For instance we could add a custom sidebar and use the `BlockInspector` component to be able to edit the advanced settings for the currently selected block. (See the [API](#API) for the list of all the available components).

In the example above, there's no registered block type, in order to use the block editor successfully make sure to register some block types. For instance, registering the core block types can be done like so:

```js
import { registerCoreBlocks } from '@wordpress/block-library';

registerCoreBlockTypes();

// Make sure to load the block stylesheets too
// import '@wordpress/block-library/build-style/style.css';
// import '@wordpress/block-library/build-style/editor.css';
// import '@wordpress/block-library/build-style/theme.css';
```

## API

<!-- START TOKEN(Autogenerated API docs) -->
Expand Down