Partitioning a Fixed-Layout Graph with Canvas Zones

What This Example Builds

This example builds a full-screen relation graph that is visually divided into three colored regions. The user sees seven table-like nodes placed at fixed coordinates, six curved links between them, and a floating note window above the graph.

The graph behaves as a viewer rather than an editor. Users can inspect the arranged scene, use the built-in toolbar, drag the note window, open a shared settings panel, and export the current canvas as an image. The main point is the combination of fixed positioning, table-style node rendering, and canvas-level background partitions.

How the Data Is Organized

The graph data is declared inline as one RGJsonData object with two practical parts: a nodes array and a lines array. Each node already contains explicit x and y coordinates, so the scene is authored as a fixed composition instead of being computed by a tree or force layout.

Before layout, the code does not transform the dataset. It inserts graphData.nodes with addNodes(...), inserts graphData.lines with addLines(...), and then runs layout once to let relation-graph build the scene around those fixed positions. In a real system, the same structure could represent grouped database tables, business domains, risk zones, workflow stages, or regional ownership areas.

How relation-graph Is Used

RGProvider wraps the example so both the graph component and the floating helper panel can access the active graph context. Inside MyGraph, RGHooks.useGraphInstance() is used to load the nodes and lines, run doLayout(), then call moveToCenter() and zoomToFit() so the authored arrangement is immediately visible.

The graph options are tuned for slot-driven rendering. layout.layoutName is set to fixed, the default node border and fill are removed, the toolbar is moved to the bottom-right in horizontal mode, and lines are drawn as black standard curves with left-right junction points. The options also enable line text on the path, although this dataset does not actually provide line labels.

Two slots define the visible presentation. RGSlotOnNode replaces the default node body with MyNodeContent, which returns HTML tables keyed by node.id. RGSlotOnCanvas inserts three absolutely positioned translucent rectangles behind the graph to create the blue, green, and yellow zones. Styling is intentionally light: the SCSS mainly defines the table appearance with a white background, collapsed borders, and dark cell lines.

The floating DraggableWindow is a shared helper component rather than logic unique to this example. It uses RGHooks.useGraphStore() to read the current interaction settings, graphInstance.setOptions(...) to switch wheel and drag behavior, and the image-generation helpers to export the current canvas.

Key Interactions

The graph is loaded as a read-only overview, so the important interactions are about inspection rather than editing. Users can pan and zoom the canvas through normal relation-graph behavior and the built-in toolbar.

The floating note window can be dragged, minimized, and toggled into a settings panel. That panel lets the user switch wheel behavior between scroll, zoom, and none, switch canvas dragging between selection, move, and none, and download the current graph as an image. There are no node editing, edge editing, or dynamic regrouping actions in this demo.

Key Code Fragments

This fragment shows that the scene is authored as a fixed-layout graph with explicit coordinates and curved connectors.

const graphOptions: RGOptions = {
    defaultNodeBorderWidth: 0,
    defaultNodeColor: 'transparent',
    toolBarDirection: 'h',
    toolBarPositionH: 'right',
    toolBarPositionV: 'bottom',
    defaultLineShape: RGLineShape.StandardCurve,
    defaultJunctionPoint: RGJunctionPoint.lr,
    layout: {
        layoutName: 'fixed'
    }
};

This fragment shows that nodes and lines are loaded separately and then centered into view after layout.

const initializeGraph = async () => {
    graphInstance.addNodes(graphData.nodes);
    graphInstance.addLines(graphData.lines);
    await graphInstance.doLayout();
    graphInstance.moveToCenter();
    graphInstance.zoomToFit();
};

This fragment shows the two slots that create the example’s visible structure: table nodes in front and partition bands behind.

<RelationGraph options={graphOptions}>
    <RGSlotOnNode>
        {MyNodeContent}
    </RGSlotOnNode>
    <RGSlotOnCanvas>
        <div style={{ width: '500px', height: '800px', position: 'absolute', left: '-800px', top: '0px', backgroundColor: 'rgba(15,71,255,0.18)' }} />
        <div style={{ width: '500px', height: '800px', position: 'absolute', left: '-250px', top: '0px', backgroundColor: 'rgba(116,255,5,0.24)' }} />
        <div style={{ width: '500px', height: '800px', position: 'absolute', left: '300px', top: '0px', backgroundColor: 'rgba(255,247,9,0.24)' }} />
    </RGSlotOnCanvas>
</RelationGraph>

This fragment proves that the node slot is not decorative text replacement; it renders actual table markup for each node identity.

{node.id === 'table-1' && (
    <table className="c-data-table">
        <tr>
            <td colSpan={3}>{node.text}</td>
        </tr>
        <tr>
            <th>Column 1</th>
            <th>Column 2</th>
            <th>Column 3</th>
        </tr>
        <tr>
            <td>xxxx</td>
            <td>xxxx</td>
            <td>xxxx</td>
        </tr>
    </table>
)}

What Makes This Example Distinct

The comparison data shows that this example is not distinctive because it merely uses slots or a fixed layout. Other examples such as graph-offset, element-line-edit, and node-style4 also cover parts of that space. What stands out here is the specific combination: a compact fixed-position dataset, table-style node bodies rendered through RGSlotOnNode, and three fixed translucent partitions rendered through RGSlotOnCanvas.

Compared with canvas-bg2, this example is not about wrapper-class theme switching or restyling a tree. It uses slot-mounted overlays to create semantic regions inside one already arranged graph. Compared with element-line-edit, the slots are passive presentation layers rather than interactive endpoints. Compared with graph-offset, the canvas overlay is tied to actual graph grouping instead of an empty measurement workspace. Compared with node-style4, the node slot is part of a zoned scene composition rather than a single global node skin.

That makes this example a strong starting point when the requirement is spatial grouping in a viewer-style graph. It stays simpler than an editor, map composition, or true table-relationship demo while still showing how multiple presentation layers can work together.

Where Else This Pattern Applies

This pattern transfers well to dashboards where one graph must be divided into business regions, lifecycle stages, risk classes, or operational territories without turning the graph into a full editor. The same approach can also support architecture overviews where systems are grouped by environment, ownership boundary, or deployment zone.

It is also useful for schema-like overviews that need table-shaped nodes without implementing true foreign-key modeling. In those scenarios, the canvas slot can define the high-level grouping, while the node slot can present richer HTML summaries for each entity.