Expose Model APIs to Editor API

[gohabereg]

Problem statment

Currently model is strictly internal with two exceptions: Adapter and Collaboration Manager. The reason is simple: we don't want external plugins to mess with a model as it's the source of truth for the document state.

However, that brings two problems:

1. Each exception would require creation of a new plugin interface. There're only two for now (Collaboration Manager not even a plugin now — it should be), but no guarantee there won't be more. We, of course, can create a general interface for plugins that require model, but that would create a confusion.
2. Tools and plugins don't have any way at the moment to update the document state. Tools do have a limited ability to do so through the Adapter, but I believe there will be cases when its not enough. A good example: on merge tool would need to provide adapter with the changes; but tool doesn't know the current state of the inputs. It would be much more convenient to be able to change model through API, and then Adapter would just rerender the inputs

Proposed solution

I propose to add API methods which would update the model (e.g. insertText/removeText/etc.). We already have BlocksAPI and SelectionAPI which in a nutshell do exactly this — update the model.

We still won't expose the model itself, each method should be implemented in the API and have safeguards if required so the document state remains stable.

Advantages of this approach are:

1. The model object wouldn't be exposed at all (now it is exposed to Adapter and Collaboration Manager)
2. Tools would be able to change the model if required (another example — mention tool would need to insert/update usernames)
3. All plugins would now have unified interface, no need for exceptions
4. Because each model update would be done through an API layer, it should be possible to keep the API interface stable. Now if model API change, it would break adapter and collaboration manager
5. We can filter which methods are exposed to the external API

There are disadvantages as well:

1. We still wouldn't be able to freely change the model API if it breaks the external API. However, current implementation is worse — no way to support backwards compatibility
2. Most model methods would require a method in the API. Which increases the codebase size and cognitive load — in case model API change require Editor API change there will be three packages to update: model, core and sdk

Please share your thoughts and comments if you have any questions/concerns. Leave a comment if you support the proposal as well

[ilyamore88]

We already do the same with document methods being exposed via EditorJSModel. One more layer (+types in SDK) sounds really complicated.

[gohabereg]

Ideally when model is stabilised there won't be much need to update it.

In case we don't expose the model to plugins, we maybe can remove duplicate in the Document and just expose the model as it's going to be used only internally