Pros / cons of custom NodeViews vs regular NodeSpec

1

Hi! Another architectural question. I know that for fine-grained control over how nodes are rendered, I can use a NodeView. However, I’m also interested in the disadvantages of using NodeViews vs “plain” NodeSpecs (if a specific Node is also possible with plain NodeSpecs).

  • Are there any cons to always using NodeViews, including for “simple nodes” (for example, in terms of performance)? Is the main benefit of “simple nodes” a simpler API? Or are there other benefits?
  • If the benefit is mainly to shield off some APIs to the implementor; what are common culprits when using NodeViews (“mistakes” that might cause bugs / performance issues that people can’t make when using plain nodes)

The reason I’m asking is that while I appreciate the benefit of a “simpler” API (plain NodeSpecs), I want to weigh it against the benefit of just having (using) one API surface (albeit a more complex one) - and reducing the number of different concepts in our codebase.

1 Like
2

A custom node view has slightly more overhead (due to the added indirection in its behavior) but should otherwise not have any different behavior from the basic node rendering mechanism.

Read the docs for all the methods on node views to know exactly what you’re getting into. When implementing update, especially, don’t just blindly return true, but check whether the node being passed in is something you can represent.

1 Like
3

Clear! So if we implement the “default” update logic (and possibly some other methods) to be similar to the “plain” implementation, the downsides (e.g.: in terms of performance / stability) are minimal. Thanks!