What can plugin view do? Or what should it be used for?

#1

As state.PluginSpec.view said:

When the plugin needs to interact with the editor view, or set something up in the DOM, use this field. The function will be called when the plugin’s state is associated with an editor view.

I think “interact with the editor view” is meaning can get the state and do some transaction. but I’m confused what’s meaning about set something up in the DOM.which DOM can be modify? the editor view dom? or the node inside the editor ?

and what difference between the plugin view and nodeViews and schema and decoration?

Looking forward to your reply, Thanks!

#2

I think “interact with the editor view” is meaning can get the state and do some transaction. but I’m confused what’s meaning about set something up in the DOM.which DOM can be modify? the editor view dom? or the node inside the editor ?

By set something up in the DOM, I believe it means something outside the ProseMirror editor view dom. For example, a menubar:

<div class="editor">
  <div class="ProseMirror"/>
  <div class="menubar"/>
</div>

Here, you create the element outside of the ProseMirror editor because you want to fully control its style, where it mounts onto the page, etc. while having it still be reactive to changes in the editor via the editorview.

In contrast, a NodeView is used to control how a specific node is rendered (like a codeblock) but is within the editorview and semi-managed by ProseMirror. There are a limit set of hooks like update, destroy to control the NodeView similar to that of a PluginView (but more scoped / granular); they’re only called a change affects a node, not when a change affects the editor view.

<div class="editor">
  <div class="ProseMirror"/>
    <p>Hello World</p>
    <CustomNodeView/>
  <div class="menubar"/>
</div>
1 Like
#3

We tend to think about the “view” section in the same way we think about a “useEffect” hook in React. The update function can be treated like the “deps” array in useEffect and then you can use destroy to do a final clean up. It’s a really great spot to react to state changes and then perform side effects. This could include

  • Manipulating the dom outside of view.dom
  • Setting up global listeners and observers (like custom selectionchanges, window resizes, etc.)
  • Data fetching
  • Performing hacky workarounds to smooth over OS issues (not ideal but it’s still another tool for some stuff)
  • Notifying other parts of your application when something changes or if you have to save content (e.g. like executing a callback when the content of the Prosemirror document changes)

I almost think “view” should just be called “effects”

1 Like
#4

The “effects” analogy is really brilliant。