Bootstrap some documentation for the block editor module

[youknowriad]

Related #14043

This PR enhances the README of the block editor module explaining how we can use it in a any context.

[gziolo]

It looks like a very nice improvement. I left some minor comments (mostly with typos) which should be addressed before the merge. There is also an open question left solely out of curiosity.

[gziolo]

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.

[youknowriad]

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

[gziolo]

Awesome, I like where it is heading 👍

[aduth]

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:

gutenberg/packages/block-editor/src/components/provider/index.js

Lines 95 to 99 in d9768ad

	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.

[youknowriad]

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.

[aduth]

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