尧图网站建设 
Headlamp 插件开发深入理解 DefaultAppBarAction 枚举与顶部应用栏App Bar扩展机制【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp导读DefaultAppBarAction是 Headlamp 插件 APIplugin/registry模块中定义的一个枚举类型它枚举了 Headlamp 顶部应用栏App Bar上所有内置默认操作action的固定 ID例如集群选择器、通知、设置、用户菜单等。本文以该枚举为切入点结合 Headlamp 前端源码完整讲解应用栏的组成结构、内置操作的注册位置、插件如何通过registerAppBarAction向应用栏追加自定义组件以及如何通过 Processor 对内置操作进行过滤与重排。读完本文你将能够在自己的 Headlamp 插件中精准定位、替换或移除顶部应用栏的任意默认操作。一、DefaultAppBarAction 是什么DefaultAppBarAction是 Headlamp 插件 API 中plugin/registry模块导出的枚举Enumeration定义在 frontend/src/redux/actionButtonsSlice.ts。它的作用是为 Headlamp 顶部应用栏中的内置操作提供一组稳定的字符串标识符方便插件开发者引用这些内置槽位。在官方 API 文档plugin_registry.DefaultAppBarAction中记录了四个枚举成员而从当前仓库源码 actionButtonsSlice.ts 可以看到该枚举实际上包含五个成员GLOBAL_SEARCH为较新版本新增枚举成员值含义CLUSTERCLUSTER应用栏中的集群选择器 / 当前集群标题NOTIFICATIONNOTIFICATION通知入口当前版本默认渲染为null占位SETTINGSSETTINGS设置按钮USERUSER用户菜单账号、登出等GLOBAL_SEARCHGLOBAL_SEARCH全局搜索按钮桌面端宽度下显示说明官方 API 文档生成的枚举成员列表对应源码中的 L42-L45即CLUSTER、NOTIFICATION、SETTINGS、USER四个GLOBAL_SEARCH定义在 actionButtonsSlice.ts:65属于后续补充的成员。以当前仓库源码为准该枚举共 5 个成员。该枚举通过plugin/registry模块对外导出见 plugin/registry.tsx:56 与 plugin/registry.tsx:1411 的 re-export插件侧可从kinvolk/headlamp-plugin/lib中直接引入import { DefaultAppBarAction } from kinvolk/headlamp-plugin/lib;插件 SDK 的导出入口位于 plugins/headlamp-plugin/src/index.ts其中同时导出了DefaultAppBarAction与registerAppBarAction。二、应用栏的组成内置操作的默认槽位DefaultAppBarAction之所以称为“默认”操作是因为 Headlamp 的顶部应用栏TopBar在渲染时已经预先固定了这些操作的位置。核心渲染逻辑在 frontend/src/components/App/TopBar.tsx。在桌面端宽度下PureTopBar构建的默认操作数组allAppBarActions见 TopBar.tsx:488-L530顺序如下const allAppBarActions: AppBarAction[] [ { id: DefaultAppBarAction.GLOBAL_SEARCH, action: GlobalSearch / }, { id: DefaultAppBarAction.CLUSTER, action: ClusterTitle ... / }, ...appBarActions, // ← 插件注册的自定义操作被插入到这里 { id: DefaultAppBarAction.NOTIFICATION, action: null }, { id: DefaultAppBarAction.SETTINGS, action: SettingsButton ... / }, { id: DefaultAppBarAction.USER, action: showUserMenu ? IconButton .../ : null }, ];关键点在于...appBarActions展开位置插件通过registerAppBarAction注册的操作会被 Redux store 收集到state.actionButtons.appBarActions数组中并在渲染时展开在GLOBAL_SEARCH/CLUSTER与NOTIFICATION之间。每个内置操作都有固定 IDCLUSTER、NOTIFICATION、SETTINGS、USER、GLOBAL_SEARCH这些 ID 正是DefaultAppBarAction枚举的成员值。移动端小屏布局不同在(max-width:960px)下TopBar会将大部分操作折叠进“更多”菜单AppBarActionsMenu移动端的默认操作数组allAppBarActionsMobile定义在 TopBar.tsx:421-L471其中NOTIFICATION同样为null占位CLUSTER使用ClusterTitle组件。三、底层数据结构AppBarAction 与 actionButtonsSliceDefaultAppBarAction所标识的每个操作其运行时形态是AppBarAction类型。类型定义同样在 frontend/src/redux/actionButtonsSlice.tsexport type AppBarAction { id: string; action?: AppBarActionType; // ReactNode | ReactElement | (() ReactNode) | null };应用栏状态由 Redux 的actionButtonsSlice管理actionButtonsSlice.ts:128-L168它维护了四个状态字段状态字段用途headerActions详情视图Details View头部操作headerActionsProcessors详情视图头部操作处理器appBarActions应用栏操作列表appBarActionsProcessors应用栏操作处理器列表与DefaultAppBarAction直接相关的是后两者。slice 提供两个 reducersetAppBarAction向appBarActions数组追加一个操作actionButtonsSlice.ts:155-L157setAppBarActionsProcessor向appBarActionsProcessors追加一个处理器处理器用于对操作列表进行过滤/排序/修改actionButtonsSlice.ts:159-L166。处理器相关的类型定义actionButtonsSlice.ts:78-L83export type AppBarActionsProcessorArgs { actions: AppBarAction[] }; export type AppBarActionProcessorType (info: AppBarActionsProcessorArgs) AppBarAction[]; export type AppBarActionsProcessor { id: string; processor: AppBarActionProcessorType; };处理器接收当前完整的操作列表包含所有内置默认操作与插件操作返回处理后的新列表。四、registerAppBarAction向应用栏注入自定义组件插件向应用栏添加组件的唯一入口是registerAppBarAction定义在 frontend/src/plugin/registry.tsx:598-L605。其签名如下源自 plugin_registry 模块文档function registerAppBarAction( headerAction: | AppBarAction | AppBarActionsProcessor | AppBarActionProcessorType | AppBarActionType ): void官方 API 文档plugin/registry模块的registerAppBarAction条目给出了一个可直接运行的示例import { registerAppBarAction } from kinvolk/headlamp-plugin/lib; import { Button } from mui/material; function ConsoleLogger() { return ( Button onClick{() { console.log(Hello from ConsoleLogger!) }} Print Log /Button ); } registerAppBarAction(ConsoleLogger);运行后Print Log按钮会出现在 Headlamp 顶部应用栏中位于CLUSTER集群标题与NOTIFICATION之间。4.1 参数的类型与自动判定registerAppBarAction的实现在内部通过isProcessor判断registry.tsx:562-L570function isProcessor( headerAction: AppBarActionType | AppBarAction | AppBarActionsProcessor | AppBarActionProcessorType ): boolean { return !!( headerAction (has(headerAction, processor) || (typeof headerAction function headerAction.length 1)) ); }判定规则如果参数是包含processor字段的对象即AppBarActionsProcessor或是一个只接收 1 个参数的函数即AppBarActionProcessorType则会被分发到setAppBarActionsProcessor作为处理器注册其余情况React 元素、函数组件、null或AppBarAction对象通过setAppBarAction作为普通操作追加到列表。4.2 传入带 id 的 AppBarAction 对象除直接传组件外也可以传完整的AppBarAction对象以携带自定义 idregisterAppBarAction({ id: my-custom-action, action: MyCustomButton /, });4.3 处理器的归一化当传入的函数处理器被加入 Redux store 时_normalizeProcessoractionButtonsSlice.ts:106-L126会自动为其补一个生成的id格式为generated-id-${Date.now().toString(36)}确保每次注册的处理器都拥有唯一标识。五、操作处理器过滤、移除与重排默认操作由于处理器接收的是完整操作列表包含DefaultAppBarAction内置槽位因此可以精确地控制哪些操作显示、以什么顺序显示。5.1 移除内置操作例如屏蔽默认的“用户菜单”USER和“通知”NOTIFICATIONimport { DefaultAppBarAction, registerAppBarAction, } from kinvolk/headlamp-plugin/lib; registerAppBarAction(({ actions }) { return actions.filter( action action.id ! DefaultAppBarAction.USER action.id ! DefaultAppBarAction.NOTIFICATION ); });这里传入的是单参数函数registerAppBarAction会自动识别其为处理器AppBarActionProcessorType。5.2 在指定位置插入操作因为处理器可以返回任意顺序的数组也可以将自定义操作插入到任意内置槽位之前/之后registerAppBarAction(({ actions }) { const myAction { id: my-banner, action: MyBanner / }; const index actions.findIndex(a a.id DefaultAppBarAction.SETTINGS); const result [...actions]; result.splice(index -1 ? result.length : index, 0, myAction); return result; });5.3 渲染管线处理器的执行位置在 TopBar.tsx:69-L80 的processAppBarActionsexport function processAppBarActions( appBarActions: AppBarAction[], appBarActionsProcessors: AppBarActionsProcessor[] ): AppBarAction[] { let appBarActionsProcessed [...appBarActions]; for (const appBarActionsProcessor of appBarActionsProcessors) { appBarActionsProcessed appBarActionsProcessor.processor({ actions: appBarActionsProcessed, }); } return appBarActionsProcessed; }处理器按注册顺序依次串行执行前一个处理器的输出是后一个处理器的输入最终结果传入AppBarActions/AppBarActionsMenu渲染。每个操作组件还会被ErrorBoundary包裹TopBar.tsx:256-L267单个插件组件渲染出错不会拖垮整个应用栏。六、实践一个完整的应用栏插件示例综合以上内容一个同时注册“自定义操作 处理器”的完整插件代码如下import { DefaultAppBarAction, registerAppBarAction, } from kinvolk/headlamp-plugin/lib; import { Button, Chip } from mui/material; function ClusterHealthButton() { return ( Button sizesmall onClick{() alert(Cluster is healthy!)} Health /Button ); } // 1) 注册自定义操作 registerAppBarAction(ClusterHealthButton); // 2) 注册处理器移除默认通知槽位并确保自定义操作紧跟在集群选择器之后 registerAppBarAction(({ actions }) { const filtered actions.filter(a a.id ! DefaultAppBarAction.NOTIFICATION); const healthAction { id: cluster-health, action: ClusterHealthButton / }; const clusterIndex filtered.findIndex(a a.id DefaultAppBarAction.CLUSTER); filtered.splice(clusterIndex 1, 0, healthAction); return filtered; });关于处理器与操作组件重复渲染的提示处理器在每次渲染时都会执行若在其中直接创建 React 元素建议复用组件引用或使用稳定 id避免不必要的重渲染。七、从源码确认的扩展边界与注意事项默认操作槽位随版本演进DefaultAppBarAction在 actionButtonsSlice.ts:60-L66 中定义较新版本的GLOBAL_SEARCH槽位在官方生成文档的枚举列表中尚未收录说明该枚举仍在演进插件应尽量避免依赖“槽位数量”之类的硬编码假设。NOTIFICATION目前是占位槽位在桌面端与移动端的默认数组中NOTIFICATION的action均为nullTopBar.tsx:508-L510插件可借此槽位插入自己的通知组件。移动端菜单的过滤逻辑小屏下TopBar会对处理后的移动端操作再次过滤仅渲染“真实有内容”的操作React.isValidElement或函数类型null操作不会占据菜单项TopBar.tsx:532-L542。Registry.registerAppBarAction已废弃旧式的Registry.registerAppBarAction(actionName, actionFunc)在 registry.tsx:247-L251 中标记为deprecated并会打印弃用警告请统一使用模块级registerAppBarAction。导出的插件 SDK 位置DefaultAppBarAction与registerAppBarAction均从 plugins/headlamp-plugin/src/index.ts 对外导出插件通过kinvolk/headlamp-plugin/lib引入即可无需直接依赖前端内部模块。八、小结DefaultAppBarAction虽只是一个枚举但它揭示了 Headlamp 应用栏扩展模型的核心设计内置操作以固定 ID 预置、插件操作以追加方式插入、处理器以串行管线方式统一调整。掌握该枚举的成员含义、registerAppBarAction的四种参数形态以及AppBarActionsProcessor的过滤能力你就能在插件中自由定制 Headlamp 顶部应用栏——从追加一个按钮到精确控制每个内置槽位的显隐与顺序。相关源码与示例可继续查阅 actionButtonsSlice.ts、TopBar.tsx、registry.tsx 以及官方 API 文档 plugin_registry 模块。【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Headlamp 插件开发：深入理解 DefaultAppBarAction 枚举与顶部应用栏（App Bar）扩展机制
Headlamp 插件开发深入理解 DefaultAppBarAction 枚举与顶部应用栏App Bar扩展机制【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp导读DefaultAppBarAction是 Headlamp 插件 APIplugin/registry模块中定义的一个枚举类型它枚举了 Headlamp 顶部应用栏App Bar上所有内置默认操作action的固定 ID例如集群选择器、通知、设置、用户菜单等。本文以该枚举为切入点结合 Headlamp 前端源码完整讲解应用栏的组成结构、内置操作的注册位置、插件如何通过registerAppBarAction向应用栏追加自定义组件以及如何通过 Processor 对内置操作进行过滤与重排。读完本文你将能够在自己的 Headlamp 插件中精准定位、替换或移除顶部应用栏的任意默认操作。一、DefaultAppBarAction 是什么DefaultAppBarAction是 Headlamp 插件 API 中plugin/registry模块导出的枚举Enumeration定义在 frontend/src/redux/actionButtonsSlice.ts。它的作用是为 Headlamp 顶部应用栏中的内置操作提供一组稳定的字符串标识符方便插件开发者引用这些内置槽位。在官方 API 文档plugin_registry.DefaultAppBarAction中记录了四个枚举成员而从当前仓库源码 actionButtonsSlice.ts 可以看到该枚举实际上包含五个成员GLOBAL_SEARCH为较新版本新增枚举成员值含义CLUSTERCLUSTER应用栏中的集群选择器 / 当前集群标题NOTIFICATIONNOTIFICATION通知入口当前版本默认渲染为null占位SETTINGSSETTINGS设置按钮USERUSER用户菜单账号、登出等GLOBAL_SEARCHGLOBAL_SEARCH全局搜索按钮桌面端宽度下显示说明官方 API 文档生成的枚举成员列表对应源码中的 L42-L45即CLUSTER、NOTIFICATION、SETTINGS、USER四个GLOBAL_SEARCH定义在 actionButtonsSlice.ts:65属于后续补充的成员。以当前仓库源码为准该枚举共 5 个成员。该枚举通过plugin/registry模块对外导出见 plugin/registry.tsx:56 与 plugin/registry.tsx:1411 的 re-export插件侧可从kinvolk/headlamp-plugin/lib中直接引入import { DefaultAppBarAction } from kinvolk/headlamp-plugin/lib;插件 SDK 的导出入口位于 plugins/headlamp-plugin/src/index.ts其中同时导出了DefaultAppBarAction与registerAppBarAction。二、应用栏的组成内置操作的默认槽位DefaultAppBarAction之所以称为“默认”操作是因为 Headlamp 的顶部应用栏TopBar在渲染时已经预先固定了这些操作的位置。核心渲染逻辑在 frontend/src/components/App/TopBar.tsx。在桌面端宽度下PureTopBar构建的默认操作数组allAppBarActions见 TopBar.tsx:488-L530顺序如下const allAppBarActions: AppBarAction[] [ { id: DefaultAppBarAction.GLOBAL_SEARCH, action: GlobalSearch / }, { id: DefaultAppBarAction.CLUSTER, action: ClusterTitle ... / }, ...appBarActions, // ← 插件注册的自定义操作被插入到这里 { id: DefaultAppBarAction.NOTIFICATION, action: null }, { id: DefaultAppBarAction.SETTINGS, action: SettingsButton ... / }, { id: DefaultAppBarAction.USER, action: showUserMenu ? IconButton .../ : null }, ];关键点在于...appBarActions展开位置插件通过registerAppBarAction注册的操作会被 Redux store 收集到state.actionButtons.appBarActions数组中并在渲染时展开在GLOBAL_SEARCH/CLUSTER与NOTIFICATION之间。每个内置操作都有固定 IDCLUSTER、NOTIFICATION、SETTINGS、USER、GLOBAL_SEARCH这些 ID 正是DefaultAppBarAction枚举的成员值。移动端小屏布局不同在(max-width:960px)下TopBar会将大部分操作折叠进“更多”菜单AppBarActionsMenu移动端的默认操作数组allAppBarActionsMobile定义在 TopBar.tsx:421-L471其中NOTIFICATION同样为null占位CLUSTER使用ClusterTitle组件。三、底层数据结构AppBarAction 与 actionButtonsSliceDefaultAppBarAction所标识的每个操作其运行时形态是AppBarAction类型。类型定义同样在 frontend/src/redux/actionButtonsSlice.tsexport type AppBarAction { id: string; action?: AppBarActionType; // ReactNode | ReactElement | (() ReactNode) | null };应用栏状态由 Redux 的actionButtonsSlice管理actionButtonsSlice.ts:128-L168它维护了四个状态字段状态字段用途headerActions详情视图Details View头部操作headerActionsProcessors详情视图头部操作处理器appBarActions应用栏操作列表appBarActionsProcessors应用栏操作处理器列表与DefaultAppBarAction直接相关的是后两者。slice 提供两个 reducersetAppBarAction向appBarActions数组追加一个操作actionButtonsSlice.ts:155-L157setAppBarActionsProcessor向appBarActionsProcessors追加一个处理器处理器用于对操作列表进行过滤/排序/修改actionButtonsSlice.ts:159-L166。处理器相关的类型定义actionButtonsSlice.ts:78-L83export type AppBarActionsProcessorArgs { actions: AppBarAction[] }; export type AppBarActionProcessorType (info: AppBarActionsProcessorArgs) AppBarAction[]; export type AppBarActionsProcessor { id: string; processor: AppBarActionProcessorType; };处理器接收当前完整的操作列表包含所有内置默认操作与插件操作返回处理后的新列表。四、registerAppBarAction向应用栏注入自定义组件插件向应用栏添加组件的唯一入口是registerAppBarAction定义在 frontend/src/plugin/registry.tsx:598-L605。其签名如下源自 plugin_registry 模块文档function registerAppBarAction( headerAction: | AppBarAction | AppBarActionsProcessor | AppBarActionProcessorType | AppBarActionType ): void官方 API 文档plugin/registry模块的registerAppBarAction条目给出了一个可直接运行的示例import { registerAppBarAction } from kinvolk/headlamp-plugin/lib; import { Button } from mui/material; function ConsoleLogger() { return ( Button onClick{() { console.log(Hello from ConsoleLogger!) }} Print Log /Button ); } registerAppBarAction(ConsoleLogger);运行后Print Log按钮会出现在 Headlamp 顶部应用栏中位于CLUSTER集群标题与NOTIFICATION之间。4.1 参数的类型与自动判定registerAppBarAction的实现在内部通过isProcessor判断registry.tsx:562-L570function isProcessor( headerAction: AppBarActionType | AppBarAction | AppBarActionsProcessor | AppBarActionProcessorType ): boolean { return !!( headerAction (has(headerAction, processor) || (typeof headerAction function headerAction.length 1)) ); }判定规则如果参数是包含processor字段的对象即AppBarActionsProcessor或是一个只接收 1 个参数的函数即AppBarActionProcessorType则会被分发到setAppBarActionsProcessor作为处理器注册其余情况React 元素、函数组件、null或AppBarAction对象通过setAppBarAction作为普通操作追加到列表。4.2 传入带 id 的 AppBarAction 对象除直接传组件外也可以传完整的AppBarAction对象以携带自定义 idregisterAppBarAction({ id: my-custom-action, action: MyCustomButton /, });4.3 处理器的归一化当传入的函数处理器被加入 Redux store 时_normalizeProcessoractionButtonsSlice.ts:106-L126会自动为其补一个生成的id格式为generated-id-${Date.now().toString(36)}确保每次注册的处理器都拥有唯一标识。五、操作处理器过滤、移除与重排默认操作由于处理器接收的是完整操作列表包含DefaultAppBarAction内置槽位因此可以精确地控制哪些操作显示、以什么顺序显示。5.1 移除内置操作例如屏蔽默认的“用户菜单”USER和“通知”NOTIFICATIONimport { DefaultAppBarAction, registerAppBarAction, } from kinvolk/headlamp-plugin/lib; registerAppBarAction(({ actions }) { return actions.filter( action action.id ! DefaultAppBarAction.USER action.id ! DefaultAppBarAction.NOTIFICATION ); });这里传入的是单参数函数registerAppBarAction会自动识别其为处理器AppBarActionProcessorType。5.2 在指定位置插入操作因为处理器可以返回任意顺序的数组也可以将自定义操作插入到任意内置槽位之前/之后registerAppBarAction(({ actions }) { const myAction { id: my-banner, action: MyBanner / }; const index actions.findIndex(a a.id DefaultAppBarAction.SETTINGS); const result [...actions]; result.splice(index -1 ? result.length : index, 0, myAction); return result; });5.3 渲染管线处理器的执行位置在 TopBar.tsx:69-L80 的processAppBarActionsexport function processAppBarActions( appBarActions: AppBarAction[], appBarActionsProcessors: AppBarActionsProcessor[] ): AppBarAction[] { let appBarActionsProcessed [...appBarActions]; for (const appBarActionsProcessor of appBarActionsProcessors) { appBarActionsProcessed appBarActionsProcessor.processor({ actions: appBarActionsProcessed, }); } return appBarActionsProcessed; }处理器按注册顺序依次串行执行前一个处理器的输出是后一个处理器的输入最终结果传入AppBarActions/AppBarActionsMenu渲染。每个操作组件还会被ErrorBoundary包裹TopBar.tsx:256-L267单个插件组件渲染出错不会拖垮整个应用栏。六、实践一个完整的应用栏插件示例综合以上内容一个同时注册“自定义操作 处理器”的完整插件代码如下import { DefaultAppBarAction, registerAppBarAction, } from kinvolk/headlamp-plugin/lib; import { Button, Chip } from mui/material; function ClusterHealthButton() { return ( Button sizesmall onClick{() alert(Cluster is healthy!)} Health /Button ); } // 1) 注册自定义操作 registerAppBarAction(ClusterHealthButton); // 2) 注册处理器移除默认通知槽位并确保自定义操作紧跟在集群选择器之后 registerAppBarAction(({ actions }) { const filtered actions.filter(a a.id ! DefaultAppBarAction.NOTIFICATION); const healthAction { id: cluster-health, action: ClusterHealthButton / }; const clusterIndex filtered.findIndex(a a.id DefaultAppBarAction.CLUSTER); filtered.splice(clusterIndex 1, 0, healthAction); return filtered; });关于处理器与操作组件重复渲染的提示处理器在每次渲染时都会执行若在其中直接创建 React 元素建议复用组件引用或使用稳定 id避免不必要的重渲染。七、从源码确认的扩展边界与注意事项默认操作槽位随版本演进DefaultAppBarAction在 actionButtonsSlice.ts:60-L66 中定义较新版本的GLOBAL_SEARCH槽位在官方生成文档的枚举列表中尚未收录说明该枚举仍在演进插件应尽量避免依赖“槽位数量”之类的硬编码假设。NOTIFICATION目前是占位槽位在桌面端与移动端的默认数组中NOTIFICATION的action均为nullTopBar.tsx:508-L510插件可借此槽位插入自己的通知组件。移动端菜单的过滤逻辑小屏下TopBar会对处理后的移动端操作再次过滤仅渲染“真实有内容”的操作React.isValidElement或函数类型null操作不会占据菜单项TopBar.tsx:532-L542。Registry.registerAppBarAction已废弃旧式的Registry.registerAppBarAction(actionName, actionFunc)在 registry.tsx:247-L251 中标记为deprecated并会打印弃用警告请统一使用模块级registerAppBarAction。导出的插件 SDK 位置DefaultAppBarAction与registerAppBarAction均从 plugins/headlamp-plugin/src/index.ts 对外导出插件通过kinvolk/headlamp-plugin/lib引入即可无需直接依赖前端内部模块。八、小结DefaultAppBarAction虽只是一个枚举但它揭示了 Headlamp 应用栏扩展模型的核心设计内置操作以固定 ID 预置、插件操作以追加方式插入、处理器以串行管线方式统一调整。掌握该枚举的成员含义、registerAppBarAction的四种参数形态以及AppBarActionsProcessor的过滤能力你就能在插件中自由定制 Headlamp 顶部应用栏——从追加一个按钮到精确控制每个内置槽位的显隐与顺序。相关源码与示例可继续查阅 actionButtonsSlice.ts、TopBar.tsx、registry.tsx 以及官方 API 文档 plugin_registry 模块。【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考