Support event optimisation for graph batch updates

[PieterT2000]

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",
  }
}

[ElGatoNinja]

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

[xShields]

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 (graphology/graphology#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.

[Yomguithereal]

@xShields I have edited your answer so your link points to the correct place.

Several things that might be of some help:

graphology graphs have #.updateEachNodeAttributes & #.updateEachEdgeAttributes methods respectively that exist to perform efficient batch updates on the graph and firing a single event that is well understood by sigma.

Rendering is of course debounced to next frame by sigma. This means it should not change anything to intercept events as soon as they happen in the same synchronous frame. Unless your performance bottleneck is CPU work done by graphology to perform a lot of tiny updates on the graph (meaning you will probably do a lot of lookups in hashmaps). In which case the methods shown above should help because they forego lookups altogether.