Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-use div/paper to show another graph #1442

Open
ialokim opened this issue Mar 15, 2021 · 3 comments
Open

Re-use div/paper to show another graph #1442

ialokim opened this issue Mar 15, 2021 · 3 comments

Comments

@ialokim
Copy link

ialokim commented Mar 15, 2021

For my application, I want to have a div that can be associated to and show different graphs one after another. Simply re-using the same div when constructing a new Paper object produces unexpected effects e.g. while dragging elements. Is there any method to properly "shutdown" a paper object before creating a new one on the very same div? I guess easiest might then even be to call paper.remove() and create a new div every time I want to switch to a different graph?

I think somehow changing the paper's associated graph (model) could be more performant, as it wouldn't require that much DOM manipulation. Is there a way to change paper.model after constructing the paper?

@kumilingus
Copy link
Contributor

Here're are 3 options.

  1. Removing the paper and create a new one is the safest way to go.
  2. Use a single paper and replace the cells only with paperGraph.resetCells(graph1.getCells())
  3. Replacing the graph is possible, not well tested though (see https://groups.google.com/g/jointjs/c/ynAwD_mO7XY/m/UAKzu_wvAQAJ)

Adding an official API for this is doable. I don't think the performance is a real issue here, since we do not expect anyone to swap papers multiple times per second. From the visual perspective you won't see a difference in any of the approaches above. It makes the garbage collector more busy though (case no. 1).

However, I do see a value in this proposal.

You can keep the same reference to the paper across your application. No need to update it when the paper changes (case no 1.).

The owner of a cell is questionable (in case no 2.). When an element is added to a graph, the reference to the graph is added to the cell i.e. property cell.graph === graph1. If you'd then add the same cell (without cloning) to another graph graph2 the reference is not changed. The owner of the cell is graph1. It can produce some issues especially if you modify both graphs.

Note that adding the graph reference can be skipped by passing dry flag.

graph1.addCells([cell1, cell2], { dry: true });
// assert: graph.getCells()[0].graph === undefined

It's open to discussion which option is better (if any or both).

paper.changeModel(graph2);
// case no.3

paper.model.fromGraph(graph2);
// makes sure it overrides the cell owner and copies all the graph attributes (not only `cells`)

My question is what exactly do you do with the graphs, which are not connected to the paper. Just trying to better understand the use-case.

graph1.fromJSON(json1);
graph2.fromJSON(json2);
// what actions are performed here with graph1 and graph2 before:
paperGraph.changeModel(graph1);

If none actions are performed, this would be an equivalent code:

paperGraph.model.fromJSON(json1);

@ialokim
Copy link
Author

ialokim commented Mar 16, 2021

Wow, thanks for your extensive answer! I went with case no. 1 for the time being and it works, but still feels like quite a lot of overhead (especially the DOM manipulation).

My use case is as follows: I have different graphs that are not related to each other, having different element objects etc. but all from the same cellNamespace. I only want to show one graph at a time at the same place in the UI, and the papers for all graphs would have the same options (e.g. for validateConnection or defaultRouter). I wouldn't do anything with the graphs while not being shown. You could imagine some kind of "tab-style" UI where every tab would contain a paper of a different graph, but instead of having different papers that I would have to hide and show again, I would like to emulate the tab behavior by simply changing the graph connected to the only paper actually present. So indeed not switching multiple times per second, but perhaps once or twice per second when "searching for the right tab".

I also have been considering the toJSON/fromJSON approach but it felt a bit bad performance-wise, too, to create new objects all the time when switching from one graph to another.

@github-actions
Copy link

github-actions bot commented May 5, 2022

This issue is stale because it has been open 60 days with no activity. Please remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale This issue/PR shows no activity for an extended period of time. label May 5, 2022
@kumilingus kumilingus added enhancement and removed stale This issue/PR shows no activity for an extended period of time. labels May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants