Deco 编辑器高扩展性技术架构解析

1.背景

Deco 人工干预页面编辑器是 Deco 工作流重要的一环，Deco 编辑器实现对 Deco 智能还原链路 输出的结果进行可视化编排，在 Deco 编辑器中修改智能还原输出的 Schema ，最后改造后的 Schema 经过 DSL 处理之后下载目标代码。

为了赋能业务，打造智能代码生态，Deco 编辑器除了满足通用的静态代码下载场景，还需要针对不同的业务方做个性化定制开发，这就必须让 Deco 编辑器架构设计更加开放，同时在开发层面需要能满足二次开发的场景。

基于上述背景，在进行编辑器的架构设计时主要追求以下几个目标：

• 编辑器界面可配置，可实现定制化开发；
• 实现第三方组件实时更新渲染；
• 数据、状态与视图解耦，模块之间高内聚低耦合；

2.业务逻辑

2.1 业务逻辑分析

Deco 工作流中贯穿始终的是 D2C Schema ，Deco 编辑器的主要工作就是解析 Schema 生成布局并操作 Schema ，最后再通过 Schema 来生成代码。

入参：已语义化处理之后的 schema json 数据

出参：经过人工干预之后的 schema json 数据

相关 Schema 的介绍可以查看凹凸技术揭秘·Deco 智能代码·开启产研效率革命。

2.2 业务架构分析

Deco 编辑器主要由 导航状态栏、节点树、渲染画布、样式/属性编辑面板、面板控制栏等组成。

核心流程是对 schema 的处理过程，所以核心模块是节点树 + 渲染画布 + 样式/属性编辑面板。

节点树、样式/属性编辑面板属于较为独立的模块（业务逻辑掺杂较少，大部分是交互逻辑），可单独作为独立的模块开发。画布部分涉及布局渲染逻辑，可作为核心模块开发，导航状态以及面板控制都需要作为核心模块处理。

业务分析完成之后，我们对编辑器有了一个业务模型的初认识，选择一个合适的技术方案来实现这样的业务模型至关重要。

3.技术方案设计参考

3.1 system.js + single-spa 微前端框架

基于以上前端业务架构分析，在进行技术方案设计的时候，不难第一时间想到微前端的方案。

将编辑器中各个业务模块拆分成各个微应用，使用 single-spa 在工作台的集成环境中管理各个微应用。有以下特点：

• 在无需刷新的情况下，同一个页面可运行不同框架的应用；
• 基于不同框架实现的前端应用可以独立部署；
• 支持应用内脚本懒加载；

缺点：

• 应用和应用之间状态管理困难，需要自己实现一个状态管理机制；

Deco 编辑器暂无多应用需求。契合指数：★★

3.2 Angular

Angular 是一个成熟的前端框架，具有组件模块管理，有以下特点：

• 内置 module 管理功能，可将不同功能模块打包成一个 module；
• 内置依赖注入功能，将功能模块注入到应用中；

缺点：

• 学习曲线陡峭，对新加入项目的同学不友好；
• 加载第三方组件较复杂；

契合指数：★★★

3.3 React + theia widget + inversify.js

使用 inversify 这个依赖注入框架来对不同的 React Widget 进行注入，同时每个 Widget 可独立发包。

Widget 的编写方法参考 theia browser widget 写法，有以下特点：

• Widget 代表一个功能模块，如属性编辑模块、样式编辑模块；
• Widget 有自己的生命周期，比如在装载和卸载时有相应钩子处理方法；
• 通过 WidgetManager 统一管理所有 Widget；
• Widget 相互独立࿰