[Architecture] Separate canvas logic from diagramming

[MeMeMax]

I’ve spent quite some time researching DOM‑based (non‑HTML‑Canvas) libraries that provide core functionality such as zooming, panning, drag‑and‑drop, minimaps, and similar interactions—all bundled in a solid JavaScript (ideally TypeScript) package. Unfortunately, there are very few libraries that fit these criteria. Many are poorly maintained, abandoned, feature‑incomplete, or written only in plain JavaScript.

When I discovered ng-diagram and explored its API and codebase, my first thought was: This is exactly what I’ve been looking for. I’m sure many others are searching for a library like this as well, which made me think more about ng-diagram’s architecture.

Roughly speaking, around 90% of the library provides general-purpose canvas functionality (zooming, panning, drag and drop, etc.), while only about 10% is diagram-specific—things like edges, ports, and routing.

This leads to the discussion I’d like to start:
Have you considered extracting the canvas functionality into a separate standalone library?

[lukasz-jazwa]

Yes, if you look into the source code, you'll notice that the TypeScript engine responsible for canvas and diagram logic is already fully separated from the Angular renderer.

The engine itself is dependency-free and encapsulates all logic including the full interaction state machine (selection, panning, dragging, etc.). The Angular layer is responsible only for capturing DOM events and rendering. User interactions captured there are translated into input events defined by the engine and passed to it. This separation was a conscious design decision.

Synergy Codes, the creators of ngDiagram, specialize in diagramming solutions, and we thought that the core might eventually be useful in a framework-agnostic context. That's why we introduced this architectural split early on.

Our long-term plan is indeed to release the engine (core) as a standalone library. However, we first want to gather more feedback from the community on the current version before making that step, so we're not able to commit to a specific timeline just yet.

[MeMeMax]

Thanks for your response and it´s awesome that you took this designs decision from the start. I would love to see not only the core functionality separated but also the Angular related things. No hurry. I like the idea to collect feedback first and optimize later.