DEV Community: Ramy Othman

Auto-layout you don't have to build

Ramy Othman — Sun, 30 Aug 2026 16:12:34 +0000

Originally published on the Grafloria engineering blog.

There's a special kind of feature request: the one filed as issue #5 of a project and still generating tutorials years later. For flow libraries that's auto-layout. The mainstream answer became "integrate dagre or elk yourself", and an entire genre of blog posts exists to walk you through the wiring — graph conversion in, position mapping out, edge cases yours forever. (The sequel, "is dynamic auto layouting possible?", has 28 comments of people discovering the hard parts.)

What the wiring tutorials don't tell you

Getting dagre to emit positions is the easy afternoon. The parts that eat the week:

Which algorithm, when? Layered algorithms are right for DAGs and wrong
for hairballs; trees want tree layouts; a picker is part of the feature.
ELK is 1.4 MB. The best layered engine is also the heaviest — ship it
eagerly and your bundle audit will find it.
The second layout. Insert a node into a laid-out graph and a full re-run
scrambles every position the user has memorized. You need incremental layout, and no wiring tutorial covers it.
Don't fight the hands. If layout re-runs on every data change, it undoes
the drag your user just made. When it runs is as important as what it computes.

One call, and the four problems it absorbs

await engine.layout('elk');                                    // picker: 'auto' inspects the graph
await engine.layout('dagre', { direction: 'TB', rankSpacing: 80 });
await engine.layoutIncremental({ changed: ['inserted-id'], radius: 1 });  // the second layout

Registered names: auto, elk, dagre,
layered, tree, grid, circular,
radial, force, spectral, community.
ELK loads as a lazy chunk on first use — it costs your bundle nothing until someone actually invokes it — and runs off-thread in a Worker. And in every framework binding, the declarative form re-runs on prop-value change only, never on node data, so it structurally cannot fight a user's drag:

// React

// Angular

// Vue

See every algorithm on a real graph: layout demos · the concept guide (including the choosing table): Layout.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.

Build a workflow editor in Vue 3 — the whole thing

Ramy Othman — Sun, 30 Aug 2026 16:12:28 +0000

Originally published on the Grafloria engineering blog.

Vue gets fewer diagram tutorials than React, and the ones that exist usually stop at "nodes appear on screen". This one goes where real workflow editors go: custom node cards, ports with connection rules, ⌘Z, auto-layout, and a save format — in Vue idiom the whole way. Everything below is running code; it's the same API our Vue demo gallery exercises in CI.

1 — A canvas with taste


import { GrafloriaFlow } from '@grafloria/vue';

const nodes = [
  { id: 'trigger', type: 'step', position: { x: 60, y: 120 },
    size: { width: 220, height: 90 }, data: { title: 'New signup', kind: 'Trigger' } },
  { id: 'email', type: 'step', position: { x: 380, y: 120 },
    size: { width: 220, height: 90 }, data: { title: 'Send welcome email', kind: 'Action' } },
];
const edges = [{ id: 'e1', source: 'trigger', target: 'email' }];

          {{ data.kind }}
          {{ data.title }}

.step { height: 100%; background: #fff; border: 1.5px solid #94A5F0; border-radius: 12px;
        padding: 10px 14px; box-sizing: border-box; }
.kind { font-size: 11px; font-weight: 600; color: #3B52D9; text-transform: uppercase; }
.title { font-weight: 700; }

The #node-step slot renders every node of type step — declaring the slot is the whole custom-node opt-in. :plugins="true" mounts the minimap, zoom controls and dotted background (lazy-loaded). Give the wrapper a real height: the canvas fills its container, and 100% of zero is a blank page.

2 — Ports and the rules of connection

A workflow editor without connection rules teaches users to build broken flows. Ports carry direction; validators carry your domain:

import { registerConnectionValidator, clearConnectionValidators } from '@grafloria/element';
import { onBeforeUnmount } from 'vue';

const nodes = [
  { id: 'trigger', type: 'step', position: { x: 60, y: 120 }, size: { width: 220, height: 90 },
    data: { title: 'New signup', kind: 'Trigger' },
    ports: [{ id: 't-out', side: 'right', type: 'output' }] },
  { id: 'email', type: 'step', position: { x: 380, y: 120 }, size: { width: 220, height: 90 },
    data: { title: 'Send welcome email', kind: 'Action' },
    ports: [{ id: 'e-in', side: 'left', type: 'input' },
            { id: 'e-out', side: 'right', type: 'output' }] },
];

let dispose;
function onInit(instance) {
  dispose = registerConnectionValidator(({ sourceNode, targetNode }) => {
    if (targetNode?.getData?.('kind') === 'Trigger') return 'a Trigger has no inputs';
    return true;
  });
  instance.getEngine().setInteractionConfig({ portVisibility: 'always' });
}
onBeforeUnmount(() => { dispose?.(); clearConnectionValidators(); });

Wire it with @init="onInit". An input port refuses to start a wire, the validator vetoes with a reason your user sees, and — the part you never have to build — ⌘Z already works: every gesture is one command on the engine's history.

3 — Layout and persistence

// stop hand-placing steps: one prop
//    (or "elk" for gnarlier graphs)

// save — the whole diagram is one document:
import { DiagramSerializer } from '@grafloria/element';
const json = JSON.stringify(new DiagramSerializer().serialize(instance.getModel()));

// text for humans: the same flow as valid Mermaid, positions preserved
const text = instance.exportText();

Where to go from here

The 10-minute Vue tutorial covers the same ground interactively; the Vue deep guides go into slots, state and dashboards; and every demo in the gallery exists as a real Vue SFC with source shown. If you're coming from Vue Flow, the sourced comparison shows exactly where the boxes differ.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.

Custom nodes without the props mystery

Ramy Othman — Sun, 30 Aug 2026 16:12:14 +0000

Originally published on the Grafloria engineering blog.

Two of the most-viewed custom-node questions on Stack Overflow — "Can you pass props to a custom node?" (9.7k views) and "saving additional data to a node after it has been created" (25k views) — are really one question asked from two directions: who owns a node's data? Get that model wrong and every read and write becomes a mystery.

The mental model

A node has exactly one data home: the data dictionary on the node itself, in the diagram's model. Your component doesn't receive "props you passed" — it receives the node's data, and updating means writing to the node, not to a component. Once that clicks, every framework binding is the same pattern wearing local idiom:

// The spec — identical in all three frameworks:
{ id: 'a', type: 'card', position: { x: 80, y: 90 },
  size: { width: 230, height: 110 },
  data: { title: 'Build', owner: 'CI' } }     // ← the one data home

React — a component per type via nodeTypes, receiving
{ id, data, selected, node } (mark the spec custom: true):

function Card({ data, selected }) {
  return {data.title};
}

Vue — a named slot per type; declaring the slot is the opt-in:


    {{ data.title }}

Angular — an ng-template per type, same auto-opt-in:


    {{ data['title'] }}

And the 25k-view question: writing data later

Because the node owns its data, "saving additional data after creation" is a write to the node — tracked for undo and events like any other model change:

const node = instance.getModel().getNode('a');
node.setData('status', 'passing');   // undoable, observable, serialized
instance.renderNow();

No syncing a parallel store, no cloning the nodes array to smuggle a field in. The escape hatch is symmetric: your component/template also receives the live
node, so reads that outgrow data have somewhere to go.

Deep guides per framework: React · Vue · Angular · plain JavaScript.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.

Draggable edges that stay routed

Ramy Othman — Sun, 30 Aug 2026 16:11:58 +0000

Originally published on the Grafloria engineering blog.

The single most-voted react-flow question on Stack Overflow is disarmingly simple: "Is it possible to shape reactflow edges by dragging them?" The accepted reality in the answers: not built in — write a custom edge, manage your own control points. Anyone who has built a wiring UI knows why users keep asking: the router's idea of a good path and a human's idea of a readable path are different things.

Why "just add drag handles" fails

The naive version stores pixel positions for a bend and draws through them. It works until anything moves. Then you face the real question: when the router recomputes — because a node moved, because an obstacle appeared — what happens to the user's bend?

If the router discards it, users learn their edits don't stick and stop
making them. (This is the classic smart-router-vs-segment-tool conflict — the same one JointJS users hit when the Manhattan router and the vertex tool fight over the same path.)
If the router defers to it entirely, the edge happily runs through the
node your bend now overlaps, and the diagram starts lying.

Bends as constraints

The version that works treats a user's bend as a waypoint in the model — serialized with the edge, undoable like any edit, and handed to the router as a constraint: route through these points, avoid obstacles between them.

edges: [{
  source: 'r1', target: 'c1',
  type: 'orthogonal', router: 'avoid',
  // A user dragged the wire here once. It survives node drags, re-routes,
  // serialization, and undo — the router works around it, not over it.
  points: [{ x: 340, y: 90 }],
}]

In Grafloria you don't write the drag handling: grab any segment of a routed edge and bend it; the bend lands in points; the avoid router keeps dodging nodes on the spans between your waypoints. Delete the bend and the router owns the whole path again. The mechanics of that router — the obstacle index, the grid search, what a turn costs — are in their own deep-dive.

The details users actually feel

Fat hit targets. A 2px line is a 2px click target — another
long-lived request elsewhere. Grafloria edges hit-test against a widened invisible band, so grabbing a wire doesn't require surgical aim.
Labels ride along. An edge label is anchored to the path and draggable
itself; its position persists in the model too.
One undo per gesture. A bend, a reconnect, a label move — each is one
command, so ⌘Z behaves the way muscle memory expects.

Try it: the editable-edge demo · the concepts: Edges & routing.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.

The Angular diagram-library problem, and how not to get stranded again

Ramy Othman — Sun, 30 Aug 2026 16:11:49 +0000

Originally published on the Grafloria engineering blog.

If you maintain an Angular app that draws graphs, there's a decent chance you've lived this story. The most popular Angular-native graph library's top-reacted issue is "Angular 15 not supported" — open for years, twenty-three thumbs up, followed by the same request for 17, 14, and 12 before it. A rendering bug from 2018 is still open. Meanwhile the Stack Overflow history under its tag is install failures on each new Angular major.

To be clear about tone: this is not a dunk. Open-source maintenance is unpaid work, the maintainers gave the community something real, and every library — ours included — is one life-change away from the same curve. The useful question isn't "whose fault", it's: what should an Angular team demand from a diagram dependency so this can't strand them again?

The trap has a shape

Angular's major-version cadence means a UI library that misses two majors becomes uninstallable in new projects (peer-dependency resolution simply refuses), and the workarounds — --legacy-peer-deps, forks, vendoring — each transfer the maintenance burden to you. The other escape hatch we keep seeing is wrapping a React library in Angular, which means shipping two frameworks and bridging every event across the boundary. It works. You will not enjoy it.

Four demands to make of any diagram library

A peer range that spans majors, on record. Not a README promise — the
package.json. (Ours currently declares
^18.1.0 || ^19.0.0 || ^20.0.0.)
Proof the examples run, on every release. A gallery of screenshots proves
nothing about the current version. Every Grafloria demo is executed in CI with real pointer events on every commit — an example that breaks blocks the release. Ask any vendor: what fails your build if a demo breaks?
A framework-agnostic core. If the engine has no framework dependency, the
Angular binding is a thin layer that's cheap to keep current — and if the worst happens, your diagram logic survives a framework migration. Our Angular layer is components and signals over the same engine the React, Vue and vanilla builds use.
Full source under a real license. MIT means the ultimate fallback — you
can maintain it — is at least possible. It's the difference between a risk and a cliff.

What Angular-native actually looks like now

Signal-based two-way bindings, templates for custom nodes, zoneless-verified — no wrappers around another framework's runtime:

import { Component } from '@angular/core';
import { DiagramCanvasComponent } from '@grafloria/angular';

@Component({
  selector: 'app-flow',
  imports: [DiagramCanvasComponent],
  template: `

  `,
})
export class FlowComponent {
  nodes = [
    { id: 'a', position: { x: 60, y: 80 },  size: { width: 180, height: 80 }, data: { label: 'Start' } },
    { id: 'b', position: { x: 380, y: 80 }, size: { width: 180, height: 80 }, data: { label: 'Ship' } },
  ];
  edges = [{ id: 'e1', source: 'a', target: 'b' }];
}

Drag, connect, pan/zoom, minimap, ⌘Z — wired. Every gallery demo exists as a real Angular component with source shown: the Angular demos.

Ten-minute start: the Angular tutorial · the honest shortlist including ngx-vflow and the commercial suites: alternatives.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.

Sub-flows, groups, containers: why nesting breaks every flow library

Ramy Othman — Sun, 30 Aug 2026 16:11:35 +0000

Originally published on the Grafloria engineering blog.

Look at the top-voted feature requests of any flow library and one theme towers over the rest: users want to put things inside other things. In React Flow's tracker it's "Nested flows", "Nested Nodes" and "absolute positioning in sub flows" — sixty-plus upvotes between them, one still open. This isn't a React Flow problem. It's that nesting looks like a styling feature and is actually a
semantics feature, and half-shipping it is worse than not shipping it.

Why it's genuinely hard

The moment a node can contain nodes, every subsystem gets a second opinion:

Dragging: does moving the parent move the children? (Yes.) Does dragging a
child near the edge leave the parent? (Your call — but it must be a call, not an accident. One of the top-voted react-flow Stack Overflow questions is literally "one node drags other nodes" — accidental containment.)
Hit-testing: a click inside a container over empty space — who gets it?
The container? The canvas? The deepest nested thing under the pointer?
Serialization: if membership isn't part of the document, a saved diagram
reloads as loose boxes over a decorative rectangle.
Undo: dragging a node from one container into another touches two
containers and a membership record. One gesture must be one undo step.
Collapse: fold a container and its links must re-anchor to the header —
and unfold must restore exactly what was there, even after a save/reload.

Libraries that treat groups as a rendering trick get the first demo right and the next four bullets wrong — which is exactly why the feature requests stay open for years. The correct-but-expensive answer is that containment has to live in the model.

Containment is membership

In Grafloria a group is a model object with members, and everything else follows from that one decision:

import { GroupModel } from '@grafloria/engine';

diagram.addGroup(new GroupModel({ id: 'ingest-stage', position: { x: 0, y: 0 },
  size: { width: 320, height: 180 } }));

await engine.addToGroup('ingest-stage', 'a');   // membership is model state
await engine.collapseGroup('ingest-stage');     // reversible: a snapshot rides ON the group
await engine.expandGroup('ingest-stage');       // …so collapsed diagrams survive save/reload

Members drag with the group. Collapse stores member positions and removed links
on the group itself, so a collapsed diagram serializes and expands correctly in
a different session. Hit-testing is deepest-wins. And because group operations are commands, the cross-container drag really is one ⌘Z.

The dashboard version, since that's where nesting usually ends up

The most common concrete ask behind "nested flows" is a dashboard section: a box of KPIs that lays out its own children and accepts tiles dragged in. In our dashboard kit that's one field on a widget:

{ id: 'kpis', title: 'KPI section', span: 12, columns: 4,
  widgets: [
    { id: 'k1', kind: 'kpi', span: 1, data: { label: 'Revenue',   value: '$6.8M' } },
    { id: 'k2', kind: 'kpi', span: 1, data: { label: 'Customers', value: '1,284' } },
  ] }

Drag a tile across the boundary and the other grid adopts it live; drag it back out and the board takes it back; either way one undo restores everything, and
toJSON() reports the tile under whichever parent it's actually in —
derived from live membership, not from the array you authored. Resize a child taller than the section and the section grows a row in its board rather than letting the child overflow.

Try both live: group demos · dashboard containers · the concepts: Groups.

Grafloria is an MIT-licensed diagram engine for React, Angular, Vue and plain JavaScript — grafloria.com. If this post was useful, the demo gallery is where the ideas live as running code.