Render Multiple Disconnected Subsystem Networks in One Tree View

What This Example Builds

This example builds a full-height relation-graph viewer that shows several disconnected node groups and two fully isolated nodes on one canvas. The visual result is a tree-routed graph with black node outlines, gray curved connectors, and line labels drawn directly on the path. Its main point is that one RelationGraph instance can present fragmented data without adding synthetic links just to make the layout work.

Users do not trigger loading through a button or custom control. The graph initializes itself on mount, recenters the viewport, fits the whole canvas, and then leaves the page in a read-only inspection mode with the built-in toolbar at the bottom-right.

How the Data Is Organized

The data is authored as one module-level RGJsonData literal in MyGraph.tsx. It includes rootId: '2', a nodes array, and a lines array. The important structural detail is that the payload is not one continuous tree: one branch starts from node 2, another from node 6, another from node 10, and single-1 plus single-2 remain edge-free.

There is no preprocessing step before setJsonData(...). The example does not derive helper roots, inject invisible edges, or rebuild the dataset before layout. In real projects, the same shape could represent several subsystem inventories on one screen, partially connected equipment maps, process groups collected from different sources, or any graph where some records are still orphaned.

How relation-graph Is Used

index.tsx wraps the demo with RGProvider, and MyGraph.tsx reads the live graph instance through RGHooks.useGraphInstance(). The graph is configured entirely through the options prop on RelationGraph: node borders are set to a 1-pixel black stroke, the toolbar is placed horizontally at the bottom-right, line text is rendered on the connector path, and the line geometry uses RGJunctionPoint.lr plus RGLineShape.StandardCurve with a gray stroke color.

The layout is relation-graph’s built-in tree layout with treeNodeGapH = 100. That matters because the source data is fragmented rather than purely hierarchical, yet the example still uses tree routing to keep the branches readable. Initialization is imperative: setJsonData(...) loads the prepared payload, then moveToCenter() and zoomToFit() adjust the viewport.

There are no node, line, canvas, or viewport slots in the reviewed source, and there is no editing workflow. The local SCSS file only scopes selectors such as .rg-toolbar, .rg-node, and .rg-line-text without adding visible declarations, so most of the presentation comes from relation-graph defaults plus the explicit option values in graphOptions.

Key Interactions

• The graph loads automatically when the component mounts.
• After loading, the viewport is centered and zoomed to fit the full fragmented dataset.
• Users can inspect the result with the built-in toolbar and standard canvas navigation rather than with custom buttons or handlers.
• The reviewed source contains no custom click events, editing actions, expand/collapse logic, or runtime mode switching.

Key Code Fragments

This fragment proves that the dataset is authored inline and already includes two isolated nodes before the graph is loaded:

const myJsonData: RGJsonData = {
      rootId: '2',
      nodes: [
        { id: '2', text: 'ALTXX' },
        { id: '3', text: 'CH2 TTN' },
        { id: 'single-1', text: 'Single 1' },
        { id: 'single-2', text: 'Single 2' },

This fragment shows that the same payload contains several independent line groups rather than one continuous branch:

lines: [
    { from: '2', to: '5', text: '子系统' },
    { from: '2', to: '3', text: '子系统' },
    { from: '2', to: '4', text: '子系统' },
    // ... another disconnected cluster ...
    { from: '6', to: '13', text: '子系统' },
    { from: '6', to: '12', text: '子系统' },
    { from: '10', to: '33', text: '子系统' },
]

This fragment shows the option combination that makes the example read as a tree-routed, subsystem-style viewer instead of a generic default canvas:

const graphOptions: RGOptions = {
    defaultNodeBorderWidth: 1,
    defaultNodeBorderColor: '#000000',
    toolBarDirection: 'h',
    toolBarPositionH: 'right',
    toolBarPositionV: 'bottom',
    defaultLineTextOnPath: true,
    defaultJunctionPoint: RGJunctionPoint.lr,
    defaultLineShape: RGLineShape.StandardCurve,
    defaultLineColor: '#888888',
    layout: { layoutName: 'tree', treeNodeGapH: 100 }
};

This fragment proves that the graph instance is used imperatively after mount to load data and frame the whole result:

const initializeGraph = async () => {
    await graphInstance.setJsonData(myJsonData);
    graphInstance.moveToCenter();
    graphInstance.zoomToFit();
};

useEffect(() => {
    initializeGraph();
}, []);

This fragment shows that the example is presented as a dedicated full-height graph workspace:

<div
    className={`my-graph`}
    style={{ height: '100vh' }}
>
    <RelationGraph options={graphOptions}>
    </RelationGraph>
</div>

What Makes This Example Distinct

According to the comparison data, this example is closest to multi-group, multi-group-3, show-single-nodes, and show-single-nodes2, but it solves a different problem. Compared with multi-group, it takes the same kind of fragmented payload and turns it into a tree-routed view with curved gray labeled lines, so the result reads more like a structured subsystem map than a generic disconnected-network baseline.

Compared with multi-group-3, it stays in one deterministic layout from first render onward. There is no delayed updateOptions(...) call and no later force-layout pass. Compared with show-single-nodes and show-single-nodes2, it is the cleaner reference for truly disconnected data because the isolated nodes remain genuinely edge-free in the source payload instead of being attached through hidden helper lines.

The rare combination is explicit in the prepared comparison records: multiple disconnected clusters plus two isolated nodes, built-in tree layout, curved on-path line labels, bottom-right toolbar navigation, and a mount-only load-center-fit sequence with no editing UI and no preprocessing workaround.

Where Else This Pattern Applies

This pattern transfers to screens that need to present several related groups together even when the underlying data is incomplete or only partially connected. Typical migration targets include subsystem inventories, manufacturing-stage relationship maps, equipment and process overviews, merger-stage entity maps, and master-data quality dashboards where orphan records still need to remain visible.

It also applies when teams want to validate fragmented graph data before investing in custom rendering. A project can start with this direct RGJsonData loading pattern, confirm that disconnected groups and isolated nodes coexist cleanly on one canvas, and then add domain-specific styling or interactions later.