关于javascript: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 互相独立，扩展性强；

毛病：

• 和传统组件搭建形式区别比拟大，有肯定挑战性；
• API 多且简单，不易上手；

符合指数：★★★★

3.4 React + inversify.js + mobx + 全局插件化组件加载

应用 inversify 来对不同的插件化组件进行注入，每个插件化组件独立发包，同时应用 mobx 来治理全局状态以及状态散发。

应用插件化组件具备以下特点：

• 插件化组件独立开发，能够通过配置文件异步加载到全局并渲染；
• 插件化组件可共享全局 mobx 状态，通过 observer 自动更新；
• 通过 Module Registry 注册插件，对立治理插件加载；
• 人造符合内部业务组件加载以及渲染形式；

毛病：

• 插件开发模式较简单，须要起不同的服务。

符合指数：★★★★★

基于以上技术方案设计与参考，最终确定了全局插件化组件计划，总体的技术栈如下：

思路：

1. 搭建外围组件模块与面板管制大体框架，独立模块可动静注入并渲染
2. 异步拉取模块配置文件，通过配置渲染面板，并动静加载面板内容
3. 独立模块独自开发，应用 lerna 治理
4. 业务组件（大促 / 夸克）皆可作为独立模块加载
5. 应用依赖注入治理各个业务模块，使得数据、状态与视图解耦

4. 技术架构设计

基于以上确定的技术计划以及思路，将编辑器技术架构次要分为一下几个模块：

• ModuleRegistry
• HistoryManager
• DataCenter
• CoreStore
• UserStore

应用 inversify.js 进行模块依赖治理，通过挂载在 window 下的 Container 对立治理：

Container 是一个治理各个类实例的容器，在 Container 中获取类实例可通过 Container.get() 办法获取。

通过 inversify.js 依赖注入的个性，咱们将 HistoryManager、DataCenter 注入到 CoreStore 中，同时模块注册时应用 单例模式，CoreStore 中或 Container 中援用的 HistoryManager 和 DataCenter 就会指向同一个实例，这对于整个利用的状态一致性提供了保障。

4.1 ModuleRegistry

ModuleRegistry 是用来注册编辑器中各个容器，Nav、Panels 等等，它的次要工作是用来治理容器（加载、卸载、切换面板等）。

工作台次要分为 Nav 容器、Left 容器、Main 容器、Panels 容器:

每个容器别离承载对应的前端模块，咱们设计了一个模块配置文件module-manifest.json，用于每个容器内加载对应的 js 模块文件：

{
  "version": "0.0.1",
  "name": "deco.workbench",
  "modules": {
    "nav": {
      "version": "0.0.1",
      "key": "deco.workbench.nav",
      "files": {
        "js": ["http://dev.jd.com:3000/nav/dist/nav.umd.js"],
        "css": ["http://dev.jd.com:3000/nav/dist/style.css"]
      },
    },
    "left": {
      "version": "0.0.1",
      "key": "deco.workbench.layoute-tree",
      "files": {
        "js": ["http://dev.jd.com:3000/layout-tree/dist/layout-tree.umd.js"],
        "css": ["http://dev.jd.com:3000/layout-tree/dist/style.css"]
      }
    }
  }
}

ModuleRegistry 解决流程如下：

4.2 CoreStore

CoreStore 用来治理整个利用的状态，包含 NodeTree、History（历史记录）等。它的次要业务逻辑分为以下几点：

1. 获取 D2C Schema
2. 将 Schema 转换成 Node 构造树
3. 通过批改、增加、删除、替换等操作生成新的 Node 构造树
4. 将最新的 Node 构造树推入到 CoreStore 里注入进来的 History 实例
5. 保留 Node 构造树生成新的 D2C Schema
6. 获取最新的 D2C Schema 下载代码

CoreStore 从 Container 中注入了 HistoryManager 以及 DataCenter 的实例，大抵的应用形式是：

import {injectable, inject} from 'inversify'
import {Context, ContextData} from './context'
import {HistoryManager} from './history'
import {Schema, TYPE} from '../types'

type HistoryData = {
  nodeTree: Schema,
  context: ContextData
}

@injectable() // 申明可注入模块
class Store {
  /**
   * 历史记录
   */
  private history: HistoryManager<HistoryData>
  /**
   * 上下文数据（数据中心）*/
  private context: Context

  constructor (
    // 依赖注入
    @inject(TYPE.HISTORY_MANAGER) history: HistoryManager<HistoryData>,
    @inject(TYPE.DATA_CONTEXT) context: Context
  ) {
    this.history = history
    this.context = context
  }
}

在以上代码块中，历史记录以及数据中心均作为独立的模块被注入到 CoreStore 中，这里对相应实例的批改会影响到 Container 下的实例对象，因为它们都指向同一个实例。

4.3 HistoryManager

HistoryManager 次要是用来治理用户操作历史记录信息，基于依赖注入个性，它能够间接注入到 CoreStore 中应用，并且也能够通过 Container.get() 办法获取到最新的实例。

HistoryManager 是一个双向链表构造的抽象类，通过保留数据快照到每一个链表节点上，不便且快捷地穿梭历史记录。与一般双向链表略有不同的中央是，当 History 链表中插入一个节点时，后面的链表节点会从新链出一个新的分支。

4.4 DataCenter

数据中心是整个 Deco 编辑器用来治理楼层数据的一个独立模块，它一开始只用来服务于编辑器自身的利用开发，起初为了不便用户在编辑器利用里调试，数据中心正式以一个性能的形式积淀了下来。

楼层数据是页面节点在进行数据绑定时所用的实在数据，通过以后节点的数据上下文获取。如果将这些实在数据绑定在原有的 NodeTree 上，那咱们的 NodeTree 将是一个存储了所有信息的节点树，逻辑相当简单并且冗余，同时在做 Schema 同步时也是一个无比艰难的工作。因而，咱们思考将楼层数据独自抽出来一个模块进行治理。

如下图，ContextTree 是数据上下文的数据节点树，它和 NodeTree 上的节点一一对应绑定，并且通过地位信息（如 0-0，代表根节点的第一个子节点）绑定在一起，与 NodeTree 不同的是，它是一个具备空间关系的节点树，如地位 0-2 的节点须要插入一个上下文节点的话，须要将地位为 0-2 的 context 节点插入到地位为 0 的子节点中去，同时将地位为 0-2-0 的 context 节点设为 0-2 节点的子节点。同理，若将 0-2 节点从 ContextTree 中删掉，则须要将 0-2 节点从 0 节点子节点中删掉，并且把 0-2-0 节点设为 0 节点的子节点。

这样，便将治理数据的模块从 NodeTree 中抽离了进去，DataCenter 独立治理该页面的数据上下文，这样不仅使得咱们在代码层面做到更加解耦，同时积淀出了“数据中心”这个功能模块，不便用户在数据绑定时进行调试工作。

5 技术难点

5.1 模块治理

5.1.1 inversify

通过以上的架构剖析，咱们不难看出，尽管 Deco 编辑器次要业务性能逻辑较为简单，然而其中各个模块互相独立且相互配合，单干实现编辑器利用的数据、状态、历史以及渲染更新的操作，如果只是简略通过 ES6 Module 的模块治理是远远不够的。由此咱们引入了 inversify.js 进行模块的依赖注入治理。

inversify 是一个 IoC（Inversion of Control，管制反转）库，它是 AOP（Aspect Oriented Programming，面向切面编程）的一个 JavaScript 实现。

编辑器应用“Singleton”单例模式，每次从容器中获取类的时候都是同一个实例。不论是从类中的依赖取得实例还是从全局 Container 中取得实例都是同一个，这样的个性为整个编辑器利用状态的一致性提供了无力的保障。AOP 人造的劣势就是模块解耦，它使得编辑器利用的扩展性失去了肯定水平的进步。

更多对于 AOP 与 IoC 的介绍可参考文章羚珑 SNS 服务 AOP 与 IoC 的实际。

5.1.2 mobx

得益于 mobx 观察者模式的状态更新机制，使得状态治理与视图更新更加解耦，为编辑器的状态保护和模块治理提供了很大的便当。不同的数据状态（如 AppStore 与 UserStore）之间相互独立并且互不烦扰。

5.2 页面节点树的查找与更新

页面节点树（NodeTree）是一个针对 Schema 设计的形象树，它的次要性能是对页面节点进行增删改查等操作，同时它还映射到渲染模块进行页面画布的更新渲染，最初通过一个转化办法再转为 Schema。

NodeTree 是页面节点的形象体现，当页面设计稿比拟大（比方大促设计稿）的状况下，节点树也是一颗相当宏大的形象树，在对节点进行查找的时候，如果通过简略的深度遍历算法进行查找将有微小的性能损耗。针对这种状况，咱们通过拿到每个节点的地位信息（如 0 -0）进行索引匹配查找，这样根本实现了无伤查找。另外，基于 React 更新的机制，NodeTree 节点增加或删除之后，索引自动更新，省去了手动更新地位信息的麻烦。

同时，也是基于节点地位信息的设计，实现了后面介绍的数据上下文节点的空间信息保护。

5.3 第三方组件的加载与渲染

在 Deco 智慧代码 618 利用中有提到 Deco 组件辨认工作的流程，在 Deco 中，一份组件样本（视图）对应一个组件配置，基于组件配置的多样性，一个组件可能有多个样本。对于编辑器来说，组件辨认服务返回的类似组件举荐其实就是返回了组件的属性配置信息，编辑器只有找到对应的样本组件配置信息，就能够进行相应的替换工作。那么，第三方组件是如何加载的呢？

在文章的结尾，咱们便介绍了插件化开发模式，对于 Deco 编辑器来说，第三方组件也是一个插件，所以只须要将第三方组件库打包成一个 UMD 格局的 JavaScript 文件，并且在 module-manifest.json 文件中配置 deps 插件信息即可，这样第三方组件便以插件的模式被加载到了编辑器的全局环境中去。

同时，编辑器存储了一份第三方组件的配置表，在用户进行类似组件替换时，通过该配置表获取对应样本的配置信息给到编辑器的画布模块进行渲染。这里默认规定第三方组件应用 React 开发，编辑器在渲染的时候应用 React.createElement 原生办法进行组件渲染。

// 组件配置信息数据结构
export interface AtomComponent {
  id: string
  componentName: string
  logicHoc: string
  type: string
  image: string
  name: string
  props: any
  pkg: string
  tableName: string
  value?: string | number
  children?: (Partial<AtomComponent> | string)[] | string
  propsComponent?: Partial<AtomComponent>[]}

目前，这份配置表是打包在代码外面的，在编辑器将来的版本中，将会把这份配置表和 Deco 开放平台相交融，凋谢给用户编辑，编辑器在进行初始化加载时会以第三方配置的形式加载进来。

6 最初

目前 Deco 曾经反对了 618、11.11 等背景下的大促会场开发，并且买通了外部低代码平台一键进行代码构建和页面预览，通过 Deco 搭建的数十个楼层胜利上线，效率晋升达到 48%。

Deco 智能代码我的项目是凹凸实验室在「前端智能化」方向上的摸索，咱们尝试从设计稿生成代码（DesignToCode）这个切入点动手，对现有的设计到研发这一环节进行能力补全，进而晋升产研效率。其中应用到不少算法能力和 AI 能力来实现设计稿的解析与辨认，感兴趣的童鞋欢送关注咱们的账号「凹凸实验室」（知乎、掘金）。

7 更多文章

设计稿一键生成代码，研发智能化摸索与实际

助力双 11 个性化会场高效交付：Deco 智能代码技术揭秘

超根底的机器学习入门 - 原理篇