jacomyal
Support event optimisation for graph batch updates
Is your feature request related to a problem? Please describe.
Unless I have overlooked something, it seems that Sigma.js nor Graphology support temporarily pausing the firing of events when doing a lot of sequential updates to a graph instance.
Say that you have an existing immutable graph G. You can add multiple nodes/edges in bulk using the G.import method, but individual events will still be triggered for each node/edge.
Note: if this is already supported, please let me know 😀
Describe the solution you'd like
It would be great to have something akin to the suspendEvents and resumeEvents functions in Cesium.js.
Describe alternatives you've considered An alternative is to replace the graph instance in Sigma. However, this does not work well in React Sigma. I'd rather keep the immutability constraints in place.
Additional context Relevant dependencies:
{
"dependencies": {
"@react-sigma/core": "^5.0.2",
"sigma": "^3.0.1",
"graphology": "^0.25.4",
}
}
As this repo is starting to look a bit forgotten. For whomever might be interested in this, this is a hack to solve the missing of batch updates:
/** This hacky method intercepts and blocks events to prevent sigmajs to rerender the graph
* every single time an edge is droped in a loop, for example
* @param eventTypeToBlock the name of the event that graphology emits and we want to block (e.g: "edgeDropped")
* @param graph the graph to block on
* @param triggering_action the code that would trigger that event and we want to run without triggering it
* */
function interceptGraphEvent(
eventTypeToBlock: string,
graph: MultiDirectedGraph,
triggering_action: () => any,
): any {
const originalEmit = graph.emit;
graph.emit = function (eventType, ...args: any[]): boolean {
if (eventType === eventTypeToBlock) {
return true;
}
return originalEmit.apply(this, [eventType, ...args] as any);
};
let result: any;
try {
result = triggering_action();
} catch (e) {
console.error("Error during trigger action:", e);
} finally {
graph.emit = originalEmit;
}
}
This blocks the event emision on a graphology graph. The list of graphology events is here
Would just like to emphasize how beneficial this would be as an officially implemented solution, whether it's on the sigma or graphology side. Also, huge thank you to @ElGatoNinja , that trick allowed our team to make major progress on some blocked custom features we've been implementing (minimally viable clustering / grouping features, that were too slow due to node drop events dragging it down). Had even asked on the graphology discussion board previously (https://github.com/graphology/graphology/discussions/509). Yomguithereal was great and super responsive, but maybe I was asking the wrong question, because this is a clear winner for some common footguns performance wise.
As a side note, exploring the gephi-lite demos, it seems they clearly have implemented some similar solution over there to overcome batch updates on deleting nodes. Tried to review their code to see what they're doing differently during node drop, but can't seem to figure out where / how they accomplished similar to the event blocking behavior above.
I wish there was a better way for this community to share their custom solutions with each other. Things like this, or custom rendering solutions, or like the clustering we're working on (which seems to be a feature several teams have just rolled their own with), are the kinds of things that may not make it into the repo any time soon, but would benefit folks greatly to have centralized somewhere. While the ability to make these modifications emphasizes just how strong the roots of these projects are, it also highlights that there's a lot of work we build on top of it that goes unshared or not easily discoverable.
