I had a bug recently the revolved around the return value of update on a node view. It took me a while to figure it out and I was wondering why the behaviour I observed happened.
Here is an example that I created and there’s a toy plugin there that, on instantiation (and subsequent updates), make sure every other nodes is of type x (and if not adds one in).
This works fine when update returns false (there are two nodeViewElements surrounded by textElements) but seems to “split” the some node views (and display two copies of the same node view) when returning true. It’s not too clear from the docs what will happen in either case, although I’m assuming if I return false then PM expects that I’ve moved the node in the document myself in someway?
Sorry, that wasn’t super clear. The plugin runs a “cleanup” function as soon as it’s associated with a view that goes through all the nodes and makes sure that every other node is a node of type textElement. The only other node in this example is the nodeViewElement.
The starting schema - from the DOM (under the doc) is:
<textElement>
<nodeViewElement>
<nodeViewElement>
When the plugin runs on the initial view I expect:
which is what I get when I return false from update.
When I return false from update it returns:
<textElement>
<nodeViewElement>
<nodeViewElement> <!-- this one seems to be a referential duplicate of the first nodeView -->
<nodeViewElement>
<textElement>
In the example you can toggle true andfalse in index.js under the nodeView update function and see it change.
Ah, so the problem doesn’t really have anything to do with the plugin.
When you return true from update, you are saying “yes, I can update myself to be this node”. Unconditionally returning true is a very wrong thing to do—you’ll at least want to check whether the given node matches the type that you’re implementing.
Yes sorry - it’s nothing to do with the plugin (bit of a red herring but was the reason I was interested in it). And that sentence make much more sense - thanks!