[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"example-markdown-content:en:canvas-slot-cloud-infrastructure-topology":3},{"markdown":4,"isPaidExample":5,"isTruncated":5,"charLimit":6},"# Building a Multi-Cloud Topology Board with Canvas Slot Anchors\n\n## What This Example Builds\n\nThis 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.\n\nUsers 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.\n\n## How the Data Is Organized\n\nThe 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`.\n\nEach 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.\n\n## How relation-graph Is Used\n\nrelation-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.\n\nThe 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.\n\nThe 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.\n\n## Key Interactions\n\nThe example is intentionally view-only. There are no click handlers, editing controls, or selection-driven data updates.\n\nThe meaningful interactions are:\n\n- A loading overlay blocks the board until initialization completes.\n- After mount, the graph waits briefly, draws the connector set, recenters the scene, and zooms to fit.\n- Once revealed, users can inspect the prepared topology with the graph's normal viewport navigation.\n\n## Key Code Fragments\n\nThis fragment shows that the graph is configured as a fixed, nearly invisible rendering layer behind custom HTML content.\n\n```tsx\nconst userGraphOptions: RGOptions = {\n    debug: false,\n    layout: {\n        layoutName: 'fixed'\n    },\n    defaultNodeShape: RGNodeShape.rect,\n    defaultLineShape: RGLineShape.StandardCurve,\n    defaultJunctionPoint: RGJunctionPoint.lr,\n    defaultNodeColor: 'transparent',\n    defaultNodeBorderWidth: 0,\n    defaultLineColor: 'rgba(0, 186, 189, 1)',\n    defaultLineWidth: 2,\n};\n```\n\nThis fragment shows the mount-time bootstrapping pattern: wait for the scene, add fake lines by DOM target id, then center and fit the viewport.\n\n```tsx\nconst initializeGraph = async () => {\n    await graphInstance.sleep(1000);\n    graphInstance.addFakeLines([\n        { id: '1', from: 'el-1-1', to: 'el-1-3', lineShape: 6, lineWidth: 2 },\n        { id: '2', from: 'el-1-2', to: 'el-1-4', lineShape: 6, lineWidth: 2 },\n        { id: '3', from: 'el-2-1', to: 'el-1-4', lineShape: 6, lineWidth: 2 },\n        { id: '4', from: 'el-3-1', to: 'el-1-3', lineShape: 6, lineWidth: 2 }\n    ]);\n    graphInstance.moveToCenter();\n    graphInstance.zoomToFit();\n    setGLoading(false);\n};\n```\n\nThis fragment shows the data-to-endpoint mapping pattern: inline server metadata becomes card UI, and the server id is promoted into an `RGConnectTarget`.\n\n```tsx\n{[\n    { id: 'el-1-1', name: '#数据库服务器01', ip: '292.118.12.14' },\n    { id: 'el-1-2', name: '#数据库服务器02', ip: '292.118.12.14' },\n    { id: 'el-1-3', name: '#应用服务器01', ip: '292.118.12.14' },\n    { id: 'el-1-4', name: '#应用服务器02', ip: '292.118.12.14' }\n].map((server) => (\n    \u003Cdiv key={server.id} className=\"...\">\n        \u003CRGConnectTarget targetId={server.id} className=\"w-fit\">\n            \u003Cdiv className=\"text-[14px] text-[#333] font-bold w-fit\">{server.name}\u003C/div>\n        \u003C/RGConnectTarget>\n    \u003C/div>\n))}\n```\n\nThis fragment shows that the whole infrastructure scene is rendered inside the canvas slot instead of as visible graph nodes.\n\n```tsx\n\u003CRelationGraph options={userGraphOptions}>\n    \u003CRGSlotOnCanvas>\n        \u003Cdiv className=\"w-[400px] h-[800px] absolute -left-[250px] top-0 bg-[#74ff053d] rounded-tr-[10px]\">\n            \u003Cdiv className=\"w-fit px-[20px] h-[40px] ... bg-[#74ff053d]\">\n                \u003CCloudIcon />\n                Dr. Peng Data Center\n            \u003C/div>\n            {/* server cards */}\n        \u003C/div>\n    \u003C/RGSlotOnCanvas>\n\u003C/RelationGraph>\n```\n\n## What Makes This Example Distinct\n\nCompared 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.\n\nCompared 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.\n\nCompared 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.\n\nThe 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.\n\n## Where Else This Pattern Applies\n\nThis pattern transfers well to infrastructure and operations screens where the UI layout must stay custom and pixel-controlled:\n\n- Multi-region service maps with hand-designed environment panels\n- Security monitoring boards that connect appliances, gateways, and alert widgets\n- Data-center or rack dashboards where only selected labels need visible relationship lines\n- Business workflow walls that mix cards, counters, and status panels with a connector overlay\n\nIt 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.\n",false,500,1782615400475]