consider adding `schema` into `state` objects

I can’t find the other place this was discussed right now, but wanted to open this for discussion.

---

Right now there are two schemas: the “core” one, and the user-land one.

The core one is used internally to normalize the document after any change method are run, and never exposed to the user. It ensures that the core rules of the document model are preserved and the user never touches a document that doesn’t have them in effect. (Things like block nodes can’t have inlines, etc.)

Then there is another schema, that is passed into the <Editor>, and can be added to by plugins. This schema is normalized using the onBeforeChange handled of the “core” plugin.

---

A few issues from this current setup:

• The onBeforeChange handler is kind of awkward, in the if the schema was part of state it wouldn’t even need to exist. And it also is leaky in that it only normalizes after the other on* handlers are run, meaning that it doesn’t guarantee that a developer never sees an invalid document (according to their schema).

• Since the user-land schema isn’t part of state, we can’t normalize against it automatically in the change methods, because we don’t have access to the editor instance there.

• If you are running changes outside the editor, and just passing them back in via setState, then you actually aren’t normalizing against the user-land schema for these changes. This is unexpected, and probably is causing issues that people aren’t aware of?

So those would be solved.

But it would introduce a few new problems to find solutions for:

• If it the schema was part of state, then it would be more complex for plugins to augment it. Right now you can deal with the state in server-side environments, or in places where you don’t have the editor with all of its plugins. If schema needed to be inside state, then anywhere you were working with a document you’d need access to all of the plugins that the editor uses when working with that type of document? This seems very problematic.

• If the schema is part of state, and a normalization happens automatically when you create the state, how do you ensure that any changes to a state are always observable by the parent? This is required for collaborative situations, where any operations that occur must be logged.

---

I would love thoughts from others on this, either for or against, or with ideas for how to solve some of these problems.

[oyeanuj]

I am a little confused now… so calling editor’s onChange for external changes (say, like the toolbar) doesn’t run the normalization?

Also, +1 to @Soreine’s idea of separating out the schema part of the plugin from the behavior part. Another added advantage is that when in readOnly mode, all you need is the schema and not the behavior.

[ianstormtaylor]

@Soreine @SamyPesse I would love to hear more about what you’ve been thinking about separating the “behavior/rendering” vs. “structural” parts of the schema. I think that’s a good way to put it, and I agree that it’s something we’re probably going to need to do.

Ideally I feel like we could get to the point where “plugins” were purely the behavior/rendering. And then “schema” was purely the structural.

The tricky ones seem to be things like edit-list/table/code/etc that are both at once. They’re really more like entire “features” than plugins per se. Right now it makes total sense that inside edit-list is the place to enforce the proper structure. It just going to hard to completely split them without solving that schema issue, since otherwise you’re going to need to pull in all of your plugins on the server-side anyways?

I wonder if there’s a way that with #1258 solved we could end up in a situation where the “feature” plugins could depend on the user setting up the schema, instead of packaging it themselves.

(This might also give users more flexibility in terms of how to handle the normalizations, since the “feature” plugins really only care to see that a specific structure is enforced, not how?)

What do you think? (Or anyone else!)