使用类型化节点卡片构建基础设施拓扑查看器

这个示例构建了什么

该示例构建了一个紧凑的基础设施拓扑查看器，以一台 Web 服务器为根节点，周围连接数据库、缓存和服务节点。最终可见的效果是一个深色、监控风格的场景：主服务器显示为一张包含详细状态信息的卡片，数据库节点显示为设备式磁贴，服务节点显示为更小的功能块。

用户主要通过常规图导航来查看预先准备好的拓扑。最值得注意的是场景的构成方式：relation-graph 仍然渲染普通节点和连线，但画布级的 VPC 注释以及自定义节点主体让这张图看起来更像运维看板，而不是通用树图。

数据是如何组织的

数据是在 initializeGraph() 内部创建的内联 JSON 拓扑对象。它定义了 rootId、nodes 数组和 lines 数组，然后通过 setJsonData(...) 直接加载该结构。这里没有单独的 doLayout 预处理阶段。

关键的预处理选择体现在节点元数据上。每个节点都存储 data.type，而有些节点还携带服务器状态、IP、端口、CPU、内存、磁盘或数据库引擎等附加字段。渲染器随后根据 node.data.type 分支，以决定显示哪一种节点主体。在真实系统中，同样的结构可以表示应用服务器、缓存层、数据库实例、内部 API，或其他从资产清单服务加载的基础设施资源。

relation-graph 是如何使用的

该示例在 index.tsx 中使用 RGProvider，使 RGHooks.useGraphInstance() 能在 MyGraph.tsx 中控制图实例。图配置设置了一个从左到右的树布局，具有固定的节点间距、矩形节点几何形态、标准曲线连线，以及左右连接点处理。内置节点填充和边框被关闭，因此可见外观来自自定义插槽内容，而默认连线样式仍保持青色并略作强化。

RelationGraph 在这里作为常规节点连线图使用，而不是纯粹的连接器层。RGSlotOnNode 从同一份数据集中渲染三种不同的节点主体：服务器使用大型监控卡片，数据库使用紧凑磁贴，服务则使用简单功能磁贴。RGSlotOnCanvas 在图场景后方添加了一个带标签的 Internal Isolation Zone (VPC-1) 矩形，而且该覆盖层显式设置为不可交互，因为它使用了 pointer-events-none。

实例 API 负责启动流程。组件挂载后，会构建内联数据集，安排加载状态结束，调用 setJsonData(...)，然后执行 moveToCenter() 和 zoomToFit()。SCSS 文件则通过强制使用深色地图背景，并让内置节点外壳保持透明且带圆角，完成整个场景的视觉收尾。

关键交互

当 g_loading 为 true 时，会显示一个加载覆盖层，使图形变暗并显示加载动画。
挂载后，图会加载预设拓扑，并自动重新居中并缩放以适配视图。
VPC 背景层不会阻挡图交互，因为该覆盖层标记了 pointer-events-none。
服务器卡片在悬停时会提升阴影，从而为信息最密集的节点提供一个轻微的强调提示。

关键代码片段

这段配置表明，该场景本质上仍是一个常规树图，但内置节点外观被收敛到最小，以便由自定义节点标记定义可见 UI。

const userGraphOptions: RGOptions = {
    debug: false,
    layout: {
        layoutName: 'tree',
        from: 'left',
        treeNodeGapH: 150,
        treeNodeGapV: 20
    },
    defaultNodeShape: RGNodeShape.rect,
    defaultLineShape: RGLineShape.StandardCurve,

这段片段展示了拓扑如何从内联 JSON 加载，以及节点元数据如何被准备好以驱动不同的渲染器。

const myJsonData = {
    rootId: 'server-1',
    nodes: [
        { id: 'server-1', text: 'Web Server', data: { type: 'server', ip: '192.168.1.10', port: '80', status: 'Running', cpu: '45%', mem: '6.2GB', disk: '128GB/512GB' } },
        { id: 'db-1', text: 'User DB', data: { type: 'database', dbType: 'PostgreSQL' } },
        { id: 'db-2', text: 'Cache', data: { type: 'database', dbType: 'Redis' } },
        { id: 'svc-1', text: 'Auth Service', data: { type: 'service' } },
        { id: 'svc-2', text: 'Payment API', data: { type: 'service' } },
    ],

这段启动序列是核心运行时模式：加载内联数据集，然后让视口居中并适配显示。

setGLoading(false);
await graphInstance.setJsonData(myJsonData);
graphInstance.moveToCenter();
graphInstance.zoomToFit();

这段节点插槽片段说明，一个节点插槽会根据 data.type 分支，因此同一张图可以用不同的 HTML 主体渲染不同的基础设施角色。

const NodeSlot = ({ node }: RGNodeSlotProps) => {
    const data = node.data;

    if (data.type === 'server') {
        return (
            <div className="w-[300px] border border-gray-300 rounded-lg shadow-md bg-white overflow-hidden transition-all hover:shadow-lg">

这段画布插槽片段证明，VPC 区域是注释层，而不是实际图节点和连线的来源。

<RGSlotOnCanvas>
    <div className="absolute left-[-50px] top-[-80px] w-[400px] h-[400px] bg-[rgba(116,255,5,0.1)] border border-dashed border-green-300 pointer-events-none">
        <div className="w-fit px-5 h-10 leading-10 -mt-0 bg-[rgba(116,255,5,0.2)] text-gray-700 rounded-tr-lg flex items-center justify-center gap-1.5 font-medium">
            <Layout className="w-4 h-4" />
            Internal Isolation Zone (VPC-1)
        </div>
    </div>
</RGSlotOnCanvas>

这个示例的独特之处

对比记录清楚说明了其主要区别：这个示例把拓扑保留在普通图节点和标准加载的 lines 中，但通过类型化节点插槽和仅画布使用的背景层，让结果看起来像一个基础设施仪表板。这与 scene-network-use-canvas-slot 是不同的模式；在后者中，大部分可见看板都是直接在 RGSlotOnCanvas 里构建的，而 relation-graph 更像是 DOM 端点之间的连接器层。

与 scene-network 相比，这个示例更小，也更偏向树状结构。它不会构建完整的固定式仪表板外壳，不包含图例覆盖层、工具栏框架或手工布置的状态列。相反，它专注于一条从左到右的基础设施分支，并带有 VPC 标签和混合节点类型。

它所组合出的少见特征也很重要：从左到右的树布局、挂载时 setJsonData() 加上居中与适配初始化、由节点数据驱动的渲染器分支、青色曲线连线、深色图画布，以及不可交互的 VPC 区域注释，这些元素共同出现在一个紧凑查看器中。当团队希望获得特定场景的基础设施呈现效果，同时又不脱离标准 relation-graph 节点和连线时，它就是一个很强的起点。

这种模式还适用于哪里

需要用同一份数据集为服务器、数据库、缓存和服务渲染不同卡片主体的基础设施资产查看器。
需要在常规节点连线拓扑背后放置带标签环境区域或安全边界的运维仪表板。
应在打开时就已经居中并适配完成，而不是要求用户手动安排初始视图的内部平台地图。
对场景风格有要求，但实现上仍应依赖标准 nodes 和 lines，而不是绝对定位 HTML 面板的技术依赖看板。

基础设施拓扑看板