Building a Multi-Cloud Topology Board with Canvas Slot Anchors

What This Example Builds

This example builds a fixed, dashboard-style infrastructure board rather than a conventional node-link diagram. The visible scene is a three-panel topology view for Dr. Peng Data Center, Tencent Cloud, and Azure Cloud, each panel containing white server inventory cards with hardware details.

Users mainly inspect the prepared topology through normal graph navigation. The notable behavior is that relation-graph stays behind the custom HTML scene and only draws the curved connector layer after the component finishes its mount-time initialization.

How the Data Is Organized

The example does not load a standard nodes and lines dataset through setJsonData, and it does not run a separate doLayout preprocessing step. Instead, each cloud panel defines an inline array of server objects and maps those objects directly into card markup inside RGSlotOnCanvas.

Each server object carries an id, name, and ip, and the id is reused as the targetId for RGConnectTarget. That same id family is referenced again in addFakeLines(...), so the data model is really an endpoint registry for selected DOM labels. In a real system, the same pattern could represent application instances, database clusters, regional gateways, or rack devices that need to stay inside a predesigned operations board.

How relation-graph Is Used

relation-graph is configured as a fixed connector layer. The graph options set layout.layoutName = "fixed", use rectangular nodes and standard curved lines, force left-right junction points, and hide built-in node chrome by making nodes transparent and borderless. The cyan default line color and width establish the topology accent style.

The main composition happens in RGSlotOnCanvas, where the full board is rendered as absolute-positioned HTML. RGConnectTarget is attached to selected server-name labels, which lets fake lines bind to ordinary DOM content instead of to visible graph nodes. RGHooks.useGraphInstance() is then used to wait briefly, register four fake lines, recenter the scene, fit it to the viewport, and finally remove the loading veil.

The styling file only does a small amount of graph-skin cleanup. Its main practical effect is reinforcing transparent node rendering so the server cards remain the only visible content.

Key Interactions

The example is intentionally view-only. There are no click handlers, editing controls, or selection-driven data updates.

The meaningful interactions are:

• A loading overlay blocks the board until initialization completes.
• After mount, the graph waits briefly, draws the connector set, recenters the scene, and zooms to fit.
• Once revealed, users can inspect the prepared topology with the graph’s normal viewport navigation.

Key Code Fragments

This fragment shows that the graph is configured as a fixed, nearly invisible rendering layer behind custom HTML content.

const userGraphOptions: RGOptions = {
    debug: false,
    layout: {
        layoutName: 'fixed'
    },
    defaultNodeShape: RGNodeShape.rect,
    defaultLineShape: RGLineShape.StandardCurve,
    defaultJunctionPoint: RGJunctionPoint.lr,
    defaultNodeColor: 'transparent',
    defaultNodeBorderWidth: 0,
    defaultLineColor: 'rgba(0, 186, 189, 1)',
    defaultLineWidth: 2,
};

This fragment shows the mount-time bootstrapping pattern: wait for the scene, add fake lines by DOM target id, then center and fit the viewport.

const initializeGraph = async () => {
    await graphInstance.sleep(1000);
    graphInstance.addFakeLines([
        { id: '1', from: 'el-1-1', to: 'el-1-3', lineShape: 6, lineWidth: 2 },
        { id: '2', from: 'el-1-2', to: 'el-1-4', lineShape: 6, lineWidth: 2 },
        { id: '3', from: 'el-2-1', to: 'el-1-4', lineShape: 6, lineWidth: 2 },
        { id: '4', from: 'el-3-1', to: 'el-1-3', lineShape: 6, lineWidth: 2 }
    ]);
    graphInstance.moveToCenter();
    graphInstance.zoomToFit();
    setGLoading(false);
};

This fragment shows the data-to-endpoint mapping pattern: inline server metadata becomes card UI, and the server id is promoted into an RGConnectTarget.

{[
    { id: 'el-1-1', name: '#数据库服务器01', ip: '292.118.12.14' },
    { id: 'el-1-2', name: '#数据库服务器02', ip: '292.118.12.14' },
    { id: 'el-1-3', name: '#应用服务器01', ip: '292.118.12.14' },
    { id: 'el-1-4', name: '#应用服务器02', ip: '292.118.12.14' }
].map((server) => (
    <div key={server.id} className="...">
        <RGConnectTarget targetId={server.id} className="w-fit">
            <div className="text-[14px] text-[#333] font-bold w-fit">{server.name}</div>
        </RGConnectTarget>
    </div>
))}

This fragment shows that the whole infrastructure scene is rendered inside the canvas slot instead of as visible graph nodes.

<RelationGraph options={userGraphOptions}>
    <RGSlotOnCanvas>
        <div className="w-[400px] h-[800px] absolute -left-[250px] top-0 bg-[#74ff053d] rounded-tr-[10px]">
            <div className="w-fit px-[20px] h-[40px] ... bg-[#74ff053d]">
                <CloudIcon />
                Dr. Peng Data Center
            </div>
            {/* server cards */}
        </div>
    </RGSlotOnCanvas>
</RelationGraph>

What Makes This Example Distinct

Compared with nearby examples such as inventory-structure-diagram and interest-group, this demo does not rebuild connections from user selection. It mounts one predetermined connector set for a ready-made infrastructure board, so it is a better starting point when the relationship scene should appear automatically as part of a static dashboard.

Compared with rg-connect-target, it is less of an endpoint capability playground and more of a concrete scene recipe. The distinctive combination is fixed-layout canvas-slot composition, transparent graph-node styling, label-level RGConnectTarget anchors inside server cards, and mount-time addFakeLines() bootstrapping.

Compared with scene-network-2, the visible servers are not graph nodes at all. This example pushes further into HTML-scene composition by keeping the cards in ordinary canvas-slot markup and using relation-graph only for the connector layer and viewport control.

The loading-gated reveal also makes this example unusual within viewer-oriented canvas-slot demos. The board stays dimmed until the delayed connector registration and viewport fitting are complete, which is useful when the scene should appear already settled.

Where Else This Pattern Applies

This pattern transfers well to infrastructure and operations screens where the UI layout must stay custom and pixel-controlled:

• Multi-region service maps with hand-designed environment panels
• Security monitoring boards that connect appliances, gateways, and alert widgets
• Data-center or rack dashboards where only selected labels need visible relationship lines
• Business workflow walls that mix cards, counters, and status panels with a connector overlay

It also works as an extension pattern when a team already has a finished HTML dashboard and wants relation-graph to add connection semantics without converting the whole interface into a traditional graph dataset.