Plugin-supplied components cannot be placed above editor

As currently written, the plugins-editor only initializes plugins (attaching them to get/setEditorState functions) when the Editor component is first rendered. This means that any components supplied by plugins (like the CharCounter, WordCounter, etc of the counter plugin) cannot be placed above the Editor in a rendering method, since their first render will then be uninitialized and will crash on looking for non-existent methods (store.getEditorState is not a function).

To me, it seems limiting to require that all controls be placed below the Editor.

There are at least a couple of workarounds. For the counter plugin (to take one exampe), the components could simply check for initialization before attempting to access the bound methods:

So this line:

  const count = this.getCharCount(store.getEditorState());

could become

    let count = 0;
    if (store.getEditorState) {
      count = this.getCharCount(store.getEditorState());
    }

This kind of fix allows the components to be placed above the Editor, but still leaves an unusual difficulty with the components not remaining fully synced to the Editor’s state in all cases. Specifically, it seems that the controls (like the character count) can end up lagging behind by a single rendering cycle when something else updates the editor.

In my plugin, I needed to ensure that formatting buttons (particularly the inline ones like Bold) always correctly reflect an active / inactive state based on the current cursor position, and placing them above the editor with only the above fix left repeated issues with lagging behind a render.

I ended up solving it by having all my plugin’s components internally subscribed to re-render whenever a changed EditorState arrives, but this approach still requires the additional step, when using the plugin, of adding its callback into your onChange function.

//  in your component using the richButtons plugin
 onChange(editorState) {
  this.setState({content: editorState}, () => {
    richButtonsPlugin.onEditorChange(editorState); // re-renders the buttons as needed
  });
}

It seems that the plugin-editor itself should perhaps have another way of connecting a plugin to subscribe directly to EditorState changes, making the relative position of Editor and buttons truly irrelevant and all changes easily propagable to any plugin-supplied components and controls. Thoughts?

[juliankrispel]

Imo - we should remove state management and leave it up to userland - too many opinions about state management - makes draft-js-plugins kind of a turn-off for some

[nikgraf]

This in indeed is a problem & I didn’t anticipate it.

Possible solutions I can think of right now:

1. Some plugins don’t actually need to plugins. For example the counters e.g. WordCounter could simply be Components receiving the editorState as a prop. /cc @adrianmc

import Editor from 'draft-js-plugins-editor';
import WordCounter from 'draft-js-counter/WordCounter';

<WordCounter editorState={this.state.editorState} />
<Editor editorState={this.state.editorState} />

Still some plugins like the Mention plugin also need other things than the editorState e.g. boundingRect https://github.com/draft-js-plugins/draft-js-plugins/blob/master/draft-js-mention-plugin/src/MentionSuggestionsPortal/index.js#L22 and passing all of that might becomes annoying.

1. The second solution is the one where a re-render is forced or update internal state like you did in your plugin. This makes plugin development inherently harder.

Does your plugin actually need to be a plugin or would it work well with the first approach?

I don’t see a magic bullet solution right now 😞 Any other ideas? /cc @adrianmc @mjrussell @bkniffler