import{aw as t,y as a,z as i,b0 as r}from"./chunks/framework.D8kQE4ce.js";const u=JSON.parse('{"title":"RUNTIME","description":"","frontmatter":{},"headers":[],"relativePath":"guide/runtime.md","filePath":"guide/runtime.md"}'),d={name:"guide/runtime.md"};function o(n,e,l,s,c,h){return i(),a("div",null,e[0]||(e[0]=[r('
本章详细介绍如何深入理解tmagic-editor的打包,以及如何根据需求定制,修改tmagic-editor的页面打包发布方案。页面发布、打包相关的定制化开发,需要使用tmagic-editor的业务方,搭建好基于开源tmagic-editor的管理平台、存储服务等配套设施。
在 @tmagic/ui 部分,我们已经说过,runtime 和 UI 是配套实现的。每个版本的 runtime 都需要一个对应的 UI 来作为渲染器,实现渲染 DSL 呈现页面的功能。
一个 UI 应该至少包含一个渲染器,来实现页面渲染。同时可以提供一些基础组件。具体实现可以参考@tmagic/ui。
runtime 的 page
部分,就是真实项目页面的渲染环境。发布出去的项目页都需要基于该部分来实现渲染功能。而 page
的主要逻辑,就是需要加载 UI,同时实现业务方需要的业务逻辑,比如:
具体的 page 实现示例,可以参考
runtime 的 playground
部分,和 page
做的事情几乎一致,业务方可以包含上述 page
所拥有的全部能力。但是,因为 playground 需要被编辑器加载,作为编辑器中页面模拟器的渲染容器,和编辑器通信,接受编辑器中组件的增删改查。所以,除了保持和 page
一样的渲染逻辑之外,playground
还要额外实现一套既定通信内容和 api,才能实现和编辑器的通信功能。
在 playground 页面渲染后,需要调用接口通知编辑器完成加载。该调用需要传入一个参数 API,即挂载了增删改查功能的对象示例,提供给编辑器。
window.magic?.onRuntimeReady(API)
playground 在每次更新了页面配置后,调用一次 onPageElUpdate 并传入一个 DOM 节点,该方法作用是传入一个页面渲染组件的根节点,用来告知编辑器的模拟器遮罩如何作出反应。
window.magic.onPageElUpdate(document.querySelector('.magic-ui-page'));
API | 说明 | 参数 |
---|---|---|
updateRootConfig | 根节点更新 | root: MApp |
updatePageId | 更新当前页面 id | id: string |
select | 选中组件 | id: string |
add | 增加组件 | { config , root }: UpdateData |
update | 更新组件 | { config , root }: UpdateData |
remove | 删除组件 | { config , root }: UpdateData |
sortNode | 组件在容器间排序 | { src , dist , root }: SortEventData |
runtime 的实现示例,可以参考tmagic-editor提供的:
如介绍中提到的,tmagic-editor页面发布方案,是对构建产物 page/index.html
进行项目信息注入。项目信息就是搭建平台存储的页面配置。发布时,将注入项目信息的 page/index.html
发布出去即可。
基于上一步提到的打包原理,每次构建后,得到的产物都可以进行归档编号,存为版本。涉及到的组件改动和新增修改,体现在各个版本中。
版本管理具体如何实现,这取决于使用tmagic-editor的业务方。版本管理具有如下优点:
tmagic-editor的静态资源构建,项目配置保存,页面发布,在tmagic-editor的提供的示例方案中,流程是:
其中各个步骤的定制,可以交由业务方根据tmagic-editor提供的示例进行自定义修改。
',34)]))}const g=t(d,[["render",o]]);export{u as __pageData,g as default};