Let plugins extend State schema

[AlbertHilb]

Plugins add new functionalities to the editor. Editor State, therefore, should be able to keep also data related to these new functionalities.
To this aim, maybe, it suffices to add a new field to State, an Immutable Map, which can be used by plugins to store their own data.

What do you think?

[Rebulus]

My additional, it would be nice, if this state were personalized by plugin for excluding intersections of their state (like personal name spacing) 😊

[ianstormtaylor]

What kinds of use cases are you thinking about?

[Rebulus]

For example, we have plugin like hovering menu and we want to add a link functionality. It could be a button in hovering menu. When an user click on the button, then a link popover will be opened.
Currently, for this behavior, we should create a closure in the plugin and place there a state of opening the link popover. Of course, we should find a way, how to clear this state, when it is not needed. It would be cool, if we have some functionality to do that with using plugin system.
Sorry, if an example is not so good, but it is first, what I invented 😊

[Rebulus]

The main goal of this, I think, to find way to have communication between events in the plugin and render.

[ianstormtaylor]

Gotcha, I think that makes sense to me! I'd be open for a pull request that adds a state.data property that mimics the existing .data properties of Nodes.

[AlbertHilb]

Perfect! 😊
I'm going to create it in the next days.

[oyeanuj]

This would be great! Another usecase that I was thinking of would be using it as a central list/repository of things (like links, mentions, languages, font, etc) that are like metadata for the document. (I'm assuming it will be part of the raw JSON that is serialized/deserialized).

Thanks @AlbertHilb for suggesting this!

[soulwire]

Any progress on this @AlbertHilb? This kind of behavior would be very useful for something I'm working on too...

[oyeanuj]

@AlbertHilb I'm not sure your current direction of how this state would exist but I wanted to throw out an idea for you to consider. We could extend the state's data to be an object like:

stateData: {
  document: { ... },
  paragraphNode: { ... },
  headingNode: { ... }
}

and any change in document props would re-render the editor, whereas any change in any other key would only re-render the nodes of that relevant type.