描述
目前扩展系统主要支持在主页面中注入 React 组件或执行逻辑,但无法清晰地区分「扩展的逻辑部分」和「扩展的窗口 UI」。
这带来了一些限制:
- 扩展逻辑和 UI 混在一起,管理困难
- 弹出窗口或独立面板无法良好支持
- 如果在多个窗口中复用扩展,会导致逻辑重复执行或副作用
需求
希望扩展系统能支持扩展入口文件同时导出两个函数,用于区分逻辑和 UI:
-
activate(context)
- 用于注册扩展的逻辑,如命令、事件监听、状态管理等
- 只在主窗口加载时执行一次
-
getWindows()
- 返回一个对象,声明扩展定义的窗口组件
- 例如配置窗口、工具面板等
- 每个窗口有唯一 ID,可以通过主应用 API 打开
示例:
export function activate(context) {
context.registerCommand("sayHello", () => {
console.log("Hello from extension!");
});
}
export function getWindows() {
return {
config: MyConfigComponent,
panel: MyPanelComponent,
};
}
主应用实现思路
- 主应用加载扩展时调用
activate() 执行逻辑部分。
- 调用
getWindows() 注册扩展窗口组件到一个全局 ExtensionRegistry。
- 提供
openExtensionWindow(id, options) API,用 Tauri WebviewWindow 打开专用路由 /extension-window/:id。
- 在该路由中,根据
id 从 ExtensionRegistry 查找对应的 React 组件并渲染。
通信
- 主窗口与扩展窗口之间通过 Tauri 的事件系统 (
emit / listen) 或自定义消息总线通信。
- 确保逻辑只在主窗口运行,UI 可以在任意弹窗中独立渲染。
价值
- 扩展开发体验更清晰:逻辑和 UI 解耦
- 避免逻辑在多个窗口重复执行
- 扩展可以方便地声明和使用自定义窗口
- 更接近 VSCode 等插件系统的设计模式,生态可扩展性更强
描述
目前扩展系统主要支持在主页面中注入 React 组件或执行逻辑,但无法清晰地区分「扩展的逻辑部分」和「扩展的窗口 UI」。
这带来了一些限制:
需求
希望扩展系统能支持扩展入口文件同时导出两个函数,用于区分逻辑和 UI:
activate(context)getWindows()示例:
主应用实现思路
activate()执行逻辑部分。getWindows()注册扩展窗口组件到一个全局ExtensionRegistry。openExtensionWindow(id, options)API,用 TauriWebviewWindow打开专用路由/extension-window/:id。id从ExtensionRegistry查找对应的 React 组件并渲染。通信
emit/listen) 或自定义消息总线通信。价值