前言

作者在2020年的时候开源了易动第一个版本（开源）从0打造h5可视化搭建系统 – 易动（vue+ts+egg），这两年在公司针对装修技术方案做了大量的实践，使用过draggable方案 iframe装修方案 绝对定位方案，对其在技术，产品层面都存在更深入的理解，今天给大家带来新一代企业级H5装修方案易动v3.0

开源地址

拖拽生成h5页面，支持页面全局设置，组件，自定义URL，插件市场，公共npm组件库

基于最新vue技术栈， 易动v3.0 已上线，欢迎体验~~

YD 管理端

YD_Client 客户端

开源不易，给个Star吧~

技术栈

管理端：vue3 + vite + pinia + vueuse + TypeScript

客户端：vue3 + vite + TypeScript

集成组件库（ydh5-UI）：基于Vue3 + TypeScript进行开发

服务端：serverLess

项目架构

在正文开始之前先为大家介绍一下项目架构，我们从底层到上层依次介绍

易动3使用腾讯云serverless作为后端服务，serverless在易动系统中提供组件schema的数据存储服务，为什么使用serverless下文在说明。

易动3将客户端、管理端的公共装修组件进行了统一封装发布成为npm包，解决了以往存在的一个组件需要写、改两遍代码的核心问题。

易动管理端是项目的最核心系统，除了核心的保存，修改之外，以及一系列提供装修效率的功能，例如组件市场、辅助线、复制、粘贴、撤销、放撤销，这个低代码装修系统的上限于下限皆由此项目决定。

易动客户端功能比较单纯，主要是根据约定好的js schema结合集成组件库进行数据渲染于逻辑触发。

使用方向

这几年关于低代码领域开始不断有大厂入场，这也变相的说明了该领域巨大的提效需求，愿望是美好的，但是现实是骨感的，低代码无法做到全盘通吃，只能聚焦某个领域，易动v3.0也是这样的，他无法处理存在大量逻辑的页面，所以易动v3.0选择专注于营销单页，在营销单页领域他可以发挥自己的优势。

除了基础的按钮、图片组件外，业务组件可以做很多场景化组件，例如banner，商品专区，甚至从接口获取数据的组件都可以通过js Schema的约定进行实现

而营销单页的需求络绎不绝，这样的工作就像在工厂“打螺丝”，大部分前端开发者并不愿意做这件事情，并且工作流程比较繁琐，可能因为业务原因频繁改动，大致工作流程如下

一个再简单的单页都需要走一样的固定流程，并且一旦某个环节出现了问题就需要回滚好几步，在这儿个过程中开发者也需要跟着回滚，遍出现了频繁改样式，重复机械行为。

如果有了低代码平台 流程可以变成这样

这样的架构中权责变的更加清晰，开发者从“螺丝钉”变成了技术解决方案开发者

而业务的决定权也掌握在专人手中；大家各司其职，技术根据实际需求不断优化技术解决方案，运营使用低代码平台的搭建能力 物料能力也能提高运营的效率。

H5装修常见方案

据作者了解，目前市面上所有的低代码平台几乎都是基于Schema进行实现的，这种方案的核心原理比较简单

基于这样的Schema结构，便衍生出来了多种实现方案，在这里简单描述一下我在实际工作中都使用过方案以及他们的优缺点；

绝对定位方案

简介：所有的装修组件都是再后台直接拖拽放置，没有组件群组的概念，可以任意放置你的组件到任何地方。

优点：灵活

缺点：无法流式布局，需要维护公共组件库，操作门槛较高，需要通过技术能力填补，例如吸附辅助线。

流式布局方案

简介：装修组件遵循流式布局，从上到下从左到右进行排序，就像搭积木一件，这种方案仅限移动端

优点：操作简单

缺点：组件不够灵活，因为只能上下移动，想做到非常规布局比较麻烦，需要维护公共组件库

iframe方案

简介：将客户端通过iframe内嵌到装修管理端中，再通过postMessage进行项目间通信，客户端识别环境开启装修模式与后台进行实时通信

优点：不需要维护公共组件库 ，只需要维护客户端代码

缺点：客户端与管理端代码耦合严重 装修操作部分代码需要写在客户端中

流式布局 + 绝对定位方案

简介：为绝对定位组件增加一个流式布局的父级容器，让装修数据具备二级结构，

优点：灵活 具备可生成代码的规范结构

缺点：操作麻烦，存在一定学习成本 ，需要维护公共组件库，相对其他方案多了一层结构，难度相对更加大

易动3选择的方案

在公司生产环境项目中，凭借易动v1.0的经验，我使用了流式布局方案，最初效果还是非常不错的，那时候没想到将公共组件发布到npm，两端项目公用组件的方案，后期组件改动频繁，出现了极大的维护问题，这迫使我寻找其他出路。

为了解决流式布局中一套组件，两套代码问题，在生产环境项目中实验性的使用管理端 + 客户端耦合的iframe方案，满足了公司的需求只需要维护一套代码，并且可以将Schema抽象出来应用到单页中，实现活动页装修，iframe装修方案在公司也是沿用至今，帮助公司搭建了200+的页面。

再后来，我准备重启易动项目，开发易动v2.0，我们在易动v2.0中实验性的尝试了流式布局 + 绝对定位方案，在开发之前普遍觉得#一个天才的主意，同时具备流式布局与绝对定位方案的优点，而且易动v2.0开发技术中还存在类似易企秀的多页的需求，大概经过2个月的代码编写，最终发现还是我们的想法过于理想化，首先操作上就存在比较高的门槛，技术难度也很大，而且因为Schema结构复杂，后期代码难度也是几何级别的提升，最终我们PASS了这个方案。

在后面一段时间我一直在思考一个问题，也就是低代码的边界性，他应该做什么，他可以做什么，我们如何通过低代码来创造产品价值，在不断的思考中我也逐渐明确了开发方向，不再去想他还能做什么，而是在开发之前就确定一个目标，易动3.0将会在营销领域发挥它的作用，所有的功能都围绕这个核心目标

基于这样的目标，易动v3.0再出发，依旧采用绝对定位方案，因为绝对定位方案符合需求，难度最小，具备拓展性，后期维护性更强。

方案确定好了，接下来将会介绍一些核心的实现思路。

核心实现思路

Schema的编写

schema的结构将会决定你的装修系统的上限，一个良好的设计结构将会为后面的开发降低很大的难度，我们需要定义好页面的结构与组件的结构。

而在代码中增加组件，或者增加组件类的数据，例如在轮播图组件中增加一项轮播图，都需要通过函数return的方式进行对象创建，以免出现多个组件使用的数据为一个数据源。

在项目中增加一个组件，只需要将组件Schema push到模板变量中即可

代码位置：https://github.com/vkcyan/YD/blob/main/src/modules/component/index.ts

/**
 * 组件信息列表
 * @param name 组件名称
 * @param tempLen 本次层级
 * @returns
 */
function baseComList(name: string, tempLen) {
  const list: baseComponent[] = [
    {
      id: guid(),
      name: 'y-img',
      showTitle: `图片${tempLen}`, // 显示组件名称
      show: true,
      cssModule: {
        ...absolute(tempLen),
        ...borderData(),
        ...compSize(100, 60),
        'background-color': '#ffffff00',
      }, // 样式
      staticData: {
        imglUrl:'xxxx.png',
        ...linkData(),
      }, // 行为
      function: {}, // 方法
      animation: [], // 动画
    },
    // .....
  ]
  return list.find((e) => e.name == name)
}

例如增加一个图片组件，我们只需要将参数'y-img'，传入函数，即可得到一个图片组件的Schema，这样我们便具备搭建页面Schema树的能力。

实现拖拽

实现良好的拖拽是一件非常有难度的事情，它不仅仅是简单元素的移动，而是通过技术的手段降低装修的操作门槛。

元素位移

在易动v3.0中，弃用了以往采用的监听鼠标单次移动距离实现方案，因为这会导致快速移动后出现坐标不准确的情况，改成获取相对父级绝对坐标。

全局鼠标监听使用vueuse的useMouseInElementAPI，帮助我们获取每次的相对位置，鼠标按下同时保存元素下标，再通过watchEffect全局监听useMouseInElement的变化，拿着鼠标按下阶段保存的下标去寻找需要位移的元素，不断更新其Schema中的cssModule字段中的top与left值，进而实现元素移动。

元素缩放

我们为元素增加 上 下 左 右 左上 左下 右上 右下，八个操作点，是元素支持任意缩放功能，再点击任意缩放点的时候，我们都会保存一个标识，来确定当前点击的点是什么，然后在 全局监听鼠标移动的watchEffect中执行对应缩放逻辑，来不断更新选中的元素的 top left width height的组合值，进而实现元素缩放功能。

元素多选

支持元素位移与缩放其实已经完成了装修的最核心功能，已经可以完成简单的页面搭建了，但是仅凭位移与缩放操作起来不方便，这时候就需要开发多选功能，我们把之前保存的单个选中下标改成一个选中数组。

这里说明一下为什么保存数组下标，而不是组件的唯一id，#一个时间复杂度的问题，如果保存组件唯一id，更新组件数据就需要通过循环再找到下标，进而通过下标更新数据，这时候时间复杂度为On，而直接保存数组下标，在通过下标直接更新数据，时间复杂度为O1。

回到正题，我们开发一个选中框组件，在拖动选中框的时候判断是否包含了组件，不断更新当前选中框多选的元素，进而实现多选删除，多选拖动，等等多选功能。

目前多选框计算逻辑还比较单一，仅支持从左上向右下拖动，后续有时间会继续完善。

辅助线

辅助线是低代码系统必备功能，这将会极大的降低使用门槛，实现辅助线相对来说也是非常复杂的，假如页面有4个组件，我们点击了任意一个的时候，就需要去保存其他3个组件的 top top + height/2 top + height left left + width/2 left+width，并且将其数组保存成为字典结构，也就是ES6的Set，相对数组实现可以将时间复杂度从On2降低到On，有效避免了卡顿的情况，在被选中元素不断拖动的时候，我们会不断对比当前变化坐标与之前保存的3个组件的坐标，一旦对比到了一致，就会将其值push到存储变量，并在页面上显示，表明已经对齐。

辅助线吸附

先声明一下，辅助线吸附作者的实现还存在瑕疵，目前还在寻找更好的方案，也希望有大佬可以指点一二，目前吸附还存在一点操作上的不流畅情况，所以这部分我便不多赘述。找到最佳解决方案再更新。

时间旅行

pinia的subscribes存在差异，并且events在生产环境无法获取，导致现在线上无法相关使用

所谓时间旅行就是可以进行撤销 反撤销操作操作，，具体原理感兴趣可以看看vuex版本的实现，本质原理都是一样的，基于vuex实现 撤销 与 反撤销 的plugins，采用数组 + 单指针进行实现。

more

移动端如何读取schema，使其还原装修效果；如何实现二次编辑组件的保存到创建市场；还有很多拖拽细节的实现；章节有限，这里不再一一赘述，有兴趣可以加入微信群在一起聊聊。

基础组件or业务组件

基础组件：按钮 图片 输入框 文字 模块（html自带的标签元素）

业务组件：富文本 轮播图 若干营销组件（由开发人员定制化产出的标签元素）

在早期开发低代码，无代码产品的时候，我将绝对定位方案与基础组件绑定，业务组件与流式布局绑定，随着对低代码的深入理解，我在这里必须纠正之前的偏见，正确的观点应该是：基础组件 + 绝对定位方案更加和谐、业务组件 + 流式布局方案更加和谐。

随着将装修组件发布成为npm包，他们的隔阂已经几乎不存在，全部视为公共组件，公共npm组件包中将会抹平平台差异，任何可以描绘的组件可以看作为静态结构组件都可以被低/无代码平台使用。

关于低代码

这几年关于低代码讨论也非常多，最近一直看到大厂开源的低代码工具，例如腾讯的tmagic-editor，阿里的LowCodeEngine，还有5月28号掘金直播低代码的探索与实践，其背后是前沿开发者们对效率的思考，是从局部效率转变到全局效率思想的转变。

在技术条件有限的情况下，低代码产品的广度与深度只能选择其一，我们自然希望低代码可以做的事情越多越好，生成页面，生成代码，直接编写事件，支持单页，支持多页，支持无限嵌套dom，达到降低门槛，提效降成本的作用，甚至解放劳动力，创造更大的社会价值，但是如果没有足够的技术基础，做的功能越多，就死的越惨。所以如果你也发现存在类似需求，切勿在产品设计期间不断加功能，要专注细分领域，只有这样，低代码项目才有发光发热的机会，有了经验之后再决定做什么也不迟。

从发现需求到明确定位有很长的路要走，低代码产品从可用到好用还有很长的路要走。

其他问题

为什么易动v3.0选择绝对定位方案

易动v3.0考虑到营销页面的多样化，他并不是理想化的流式布局，而是多样化的，甚至你意想不到的UI实现方式，这也是易动v3.0使用绝对定位方案实现的一个重要原因，后续作者也会不断加强可用性，进一步降低搭建门槛。贯彻技术为业务服务，而不是业务为技术服务的理念。

为什么使用serverless

做出这个决定处于两点考虑

0. 大部分公司不会使用node作为服务端框架，接入会重写服务端。
1. 本人是前端工程师，node 以及服务端周边服务不算精通，低代码的项目核心也不在服务端，serverless满足了作者的需求，后续我会提供表结构，以及关联关系。
2. 因为腾讯云serverless已经开始收费了，后续可能会换成fastify进行服务端编写，主要看作者是否有时间，也非常欢迎有志之士为开源做出贡献。

关于PC端

易动3的实现方案是绝对定位方案，这让实现pc端装修的可能性，但是个人感觉这部分需求比较小，B端的客户都是ToC，所以并没有做相关功能开发，但是理论上可以实现的。

后续还会做什么

目前易动v3.0 并不是完整状态，因为作者比较忙碌，很多功能依旧在开发中，大家也可以提出需求，如果存在价值，作者会加入后面的工作计划。

• 数据分析能力：页面的曝光情况是客户非常关心的指标，这也是易动v3.0非常关注的功能
• 模板市场功能：物料市场也是低代码平台非常重要的功能，配合组件市场，实现团队资源最大化利用，降低搭建门槛
• 丰富业务组件：根据客户需求开发其满足业务场景的组件，达到一次开发，多次使用的效果
• 增强装修能力：组件旋转，多选组件辅助对齐，搭建页面快捷操作，进一步降低大家门槛

最后

这个开源项目将会一直做下去，未来可能也会尝试做收费版本，毕竟为爱发电还是过于理想化了，如果你也是同道中人或者有这样的需求，欢迎一起起交流学习，共同进步~