I’m using setNodeMarkup to update the paragraph algin attribute.
But when paragraph contains some inline nodeView it will cause the inline nodeViews destory and re create.
I found that it was because ViewTreeUpdater did not match the changed parargraph and will cause it being destory.
The default node renderer will fully re-render a node whenever its attributes change (because it’s rendered with a simple toDOM function that might do anything with those attributes). But if you register a node view for the node whose attributes are expected to change, you can register custom update logic with the update method, which updates the existing node in-place. (Do read the docs closely on when to return false from update, it has a bit of an error-prone interface.)
Thanks for you reply, but I found It did not call the update method of nodeView.
It just simply destroy the paragraph node, and then create again.
Are there any way to avoid this behavior?
Are you creating a node view for the paragraph, or are you still talking about the inner node’s view?
In the former case, could you create an example script that demonstrates the issue?
https://jsfiddle.net/g4bcwx5v/1/, here is the demo.
I create a node calls ‘inlne_view’ render by ‘nodeview’
And makes the paragarph support align attribute.
When I use dispatch(state.tr.setNodeMarkup(0, undefined, { align: 'center' })) to update paragraph attribute. The console info is like below.
How to make the ‘inline_view’ node reused?
Yes, what my first reply said is that you can prevent this by defining a node view for your paragraph node type.
How much overhead does this incur? For a document with thousands of blocks I am concerned about this but havent had time to load test it.
It only recreates the target paragraph and its content.
Therefore, it depends on how much content the target paragraph has.
I think it would be better to reuse the paragraph node，because I only update the attributes and not the node type.
Hi. Yes, it’ll be performant once they are all created. What I meant to ask was for document initialization.
A simple node view shouldn’t be slower to create than a standard node. It’s only when you start including non-trivial amounts of extra DOM structure in your node views that you have to worry about performance.
