Proposal: Decoupled Interactive Layout Editor (Starting with Flowcharts)

[BobcGn]

Hi Mermaid Team,

Following the highly constructive feedback on my recent PR (#7713), I am completely pivoting the architecture to respect Mermaid's core "text → SVG" philosophy and avoid invasive changes to the core API.

The Goal:
My primary objective is to solve layout limitations in complex scenarios by allowing users to manually adjust node positions. I am currently focusing on implementing and optimizing this drag-and-drop functionality for Flowcharts. Once stable, I plan to extend this exact same decoupled pattern to other applicable diagram types in the future.

Here is the proposed roadmap to achieve this without cluttering the core package:

1. Minimal Hooks in Core (mermaid-js/mermaid)

I will scale down my current PR to only add generic data-source and data-target attributes to edges. This will be a minimal, diagram-agnostic change that provides the necessary DOM hooks for any external tool to re-route edges upon node movement.

2. The Interactive UI (mermaid-js/mermaid-live-editor)

Instead of embedding the editor in the core, I propose building the drag-and-drop interaction layer within the Mermaid Live Editor (or as a standalone package).
We could introduce a "Customize Layout" button that opens a dedicated view. This view will read the rendered SVG, allow the user to drag nodes, auto-update the edge paths based on the data-* attributes, and save the customized state.

3. Future Expansion

By establishing this decoupled architecture with Flowcharts first, we create a reusable foundation. In the future, we can easily plug in support for State diagrams, Mindmaps, or other visual types without touching the core rendering logic again.

Questions for the Maintainers:

1. Does adding the generic data-source / data-target attributes to edges in the core repo sound acceptable as the foundational step?
2. Are you open to receiving PRs in the mermaid-live-editor repository to build this interactive layout tool?
3. Do you have any architectural advice on structuring the Live Editor plugin so it can easily scale to other diagram types later?

Looking forward to your thoughts!