Most performant way to replace full graph? Also: KitchenSink from webpage != demo in joint+ sources

[MariusSchmidt]

Introduction

I just took a look into the demos coming with joint+. Unfortunately the sample behaves differently from https://www.jointjs.com/demos/kitchen-sink-app. I really wanted to know, how you implemented loading new graph data, but "Load File" is not implemented there.

So my questions now is, what is the most performant way to fully replace one graph by another without triggering tons of view updates and re-renderings? Would you just used the paper.model = newGraphInstance? Would you freeze() and unfreeze() the paper? Would you first clear all the cell in the old graph and then replace? Would you instantiate a new paper? And what is the unmount() function doing?

Steps to reproduce

No response

Restrictions & Constraints

No response

Does your question relate to JointJS or JointJS+. Select both if applicable.

JointJS+

[MariusSchmidt]

I was now able to reduce the load time drastically by preparing the paper + new graph "offscreen" using a parent HTML element not attached to the DOM root. Only after the paper is fully created, I attach this element to the "live" DOM e voila: only one costly "recalculate style" call instead of many of such calls, as it was before. Is there any other source or demo using "offscreen" preparation of complex JointJS DOM for more inspiration?

[kumilingus]

What's wrong with graph.fromJSON() and graph.resetCells()?

One of the requirements of JointJS is that the document be in a "live" DOM when rendered. Functions that require measuring the size of a DOM element will not work otherwise (e.g. textWrap, finding connection points on the shape boundary).

Here's example of a diagram that can be rendered outside the render tree: https://codepen.io/jointjs/pen/poYqxoL
If your really need to go that path.

---

Note: getBBox() must return the actual bounding box at the time the method was called—even in case the element has not yet been rendered. It also does not account for any transformation applied to the element or its parents

Despite what the specification says, none of the browsers implement it.