Networks and Hierarchies

Network and hierarchy charts show relationships rather than values on two independent quantitative axes. Their node positions usually come from an application-owned layout algorithm, then flow into ordinary links, dots, and text marks.

Use these views only when topology is the question. Dense networks quickly become less legible than a matrix, grouped summary, or searchable table.

Choose the topology#

Layout, traversal, grouping, and collision handling belong to data preparation. Scales and D3 routes those algorithms to the official D3 documentation while TanStack Charts renders the typed result.

Show a strict hierarchy#

A tidy tree assigns one position per node and one link per parent-child relationship. Direct labels make a small hierarchy readable without requiring hover.

Validate the hierarchy before layout:

• Every non-root node has one valid parent.
• IDs are unique and stable.
• Cycles are rejected.
• Child order is intentional.
• Collapsed branches remain represented in application state.

The layout output can retain each original record while adding x, y, depth, and parent coordinates. Render links first, then nodes and labels. See Rules, Links, Arrows, Vectors, and Ticks and Dot and Hexagon Marks.

Reveal spatial adjacency#

A Delaunay network connects points that are neighbors in a triangulation. It answers local spatial adjacency; it does not imply a business or causal relationship unless the data model defines one.

Deduplicate undirected edges during preparation and retain the source node IDs on each edge. If the point positions change with responsive scale ranges, recompute pixel-space adjacency from the final plot geometry rather than reusing stale edges.

When Delaunay is used only for nearest-point lookup, keep the triangulation in a ChartSpatialIndexFactory instead of painting its edges. See Tooltips and Focus.

Explore an unconstrained dependency graph#

A force-directed layout can reveal clusters and bridges when positions are not already meaningful. It also introduces motion, stochastic initialization, and collision policy that can make comparison unstable.

Run the simulation outside the renderer and feed settled coordinates to the chart. For repeatable output, use deterministic initialization and a defined stopping rule. Preserve node keys so data updates reconcile existing geometry instead of replacing the complete network.

If drag-to-reposition is part of the product, store the resulting positions in application state and provide a keyboard-accessible alternative or detail control. The chart scene should remain a projection of that controlled state.

Labels, direction, and weight#

• Use arrowheads only for genuinely directed edges.
• Encode link weight sparingly; wide overlapping links can hide nodes.
• Label selected or important nodes instead of every node in a dense graph.
• Use color for stable semantic groups, not whichever cluster happens to be near another after a simulation.
• Provide a searchable list or details panel for nodes that cannot be labeled directly.

Custom link paths or non-cartesian layouts may need a public custom mark. Start with built-in links, dots, and text, then use Custom Marks and Renderers only for geometry that composition cannot express.

Production checks#

• Confirm that links represent a documented relationship.
• Bound node and edge counts or aggregate the graph before rendering.
• Keep node and edge IDs stable across revisions.
• Make layout initialization and ordering deterministic when comparison matters.
• Test disconnected nodes, cycles, missing parents, duplicate edges, and empty graphs.
• Do not rely on color or pointer hover as the only identification path.
• Preserve keyboard focus and selection after layout updates.
• Measure dense cases with Large Data.