Allow extending the editor by externally managing its content

[msurdi]

Context

We'd like to be able to externally manage the content displayed by the editor, maintaining the external behaviour already provided by the Gutenberg editor where you can pass down value, onInput and onChange props and the editor will use that to manage the data shown and the changes to it.

Changes proposed

In this pull request we are adding a new value, onInput and onChange props that will allow for externally controlling the content displayed, as well as an undoManager one which will allow for externally providing an undo implementation.

This way, we will be able to implement new features as external extensions or "plugins"

[msurdi]

Probably my only concern is that in exporting undoManager, blocks, onInput, and onChange it implies that these are something that you (as a standard client) need to be concerned about. I don't know if it's sufficient to identify them as advanced use only in the docs?

If it's possible that the new collab stuff may eventually be internalised within the isolated editor (or not needed if it goes into Gutenberg) then I wonder if it might also be worth marking them as experimental like Gutenberg does? For example __experimentalUndoManager etc

While I was doing this (and I forgot to make it explicit in this PR) my underlying thinking in the back of my mind was to make this editor behave (externally) as just the Gutenberg editor + some other additional features.

I think that following this approach will allow us to

1. Implement more features as composable plugins/components, which might or might not be on this repository
2. Allow others to implement their own features without needing to have commit rights into this repository
3. Allow for features to not be required to be included by default (as we're doing with collab).
4. Allow for applications using this to follow the very common pattern in the React world of having any UI component be as stateless as possible and have a value and onChange props to control their content.
5. Make it very easy for anyone already using the Gutenberg editor, to use this one, as it will have the same API exposed.

Finally, I think it is not 100% decided already if the collab code will be moved here. It might end up here, in Gutenberg, in a new repository, or just be removed if Gutenberg implements its own solution.

But, I think it still makes sense to rename these props to experimental as this is not yet thoroughly tested in real production applications, and we can always decide later on this.

I did see some console warnings about blocks being re-registered on the managed storybook page, but that may be a storybook thing.

Fixed! didn't realise the blocks were already registered.

[johngodley]

I wouldn't really say this is a UI component, and one of the main aims was to fully encapsulate edit history (the opposite of exposing it!) That's fine though, as needs do change, and it allows experimentation. A lot of what you listed should already be possible, but ultimately the aim is to move most of the code out of here and into Gutenberg itself. At that point a lot of these concerns fall away.

Let's 🚢 it.

[msurdi]

Hey @johngodley , I've pushed a few more commits today. Do you mind checking them? Thanks on before ✋

[johngodley]

Looks good to me!