Inconsistency with decorators and EditorState

Using version 1.1.0.

lets say we have this function:

function createState(text) {
  return EditorState.createWithContent(
    ContentState.createFromText(text)
  );
}

each time we create a new EditorState, we need to manually set the decorators. Yet, the first state we send gets the decorators from the plugins.

[philippe-git]

Just had a quick go at this, and it doesn’t seem possible (at least easily) anymore: to create a new set of combined decorators, createCompositeDecorator needs to be passed getEditorState and setEditorState, which are only available within the component itself once instantiated.

I’m not familiar enough with the codebase to know if it could be refactored in a way that makes this easier.

The only way I currently see of making such a util work would be to create it as a prototype method, and have people retrieve the Editor instance using a ref attribute, from which they’d be able to access the util. Doable but really not the best api.

My use-case (forcing the re-rendering of decorators) doesn’t require this solution specifically, I’ll implement another simple one instead, but the idea in this thread is great and would make a larger number of use-cases possible 👍

[zhouzi]

I personally have the feeling that the intention here is really to “re-build” the editor with a new blank state so it makes sense to re-instantiate the editor (and thus the decorators). The solution could be to just abstract that part in a function that returns the editor’s initial editorState to avoid the repetition.