使用 vue3 开发 前端静态编辑器 的一些思考总结

VUE3开发实践 - 前端静态页编辑器

前言：记录一次使用 vue3开发 前端静态页编辑器 的历程，包括对项目的设计构思 和 对 vue3开发的一些思考，希望可以和大家多多交流讨论。

之前也做过 react的开发，所以很多思维在这里运用到，但是相较于react，vue3开发起来会会让人感觉是一种有尺度的自由。

由于项目为公司内项目，会更多讲述技术性的内容。
主要分两方面进行介绍：
1：前端静态页面编辑器（部分偏业务的内容会删减，更多是站在项目和vue3角度下的思考）
2：不同项目/业务场景使用vue3开发的一些设计、构思

1.前端静态页面编辑器

1.1 项目背景

大多数活动页的布局大同小异、十分相似 ，很多时候开发做了重复的工作，并且修改、发版、测试等工作，还特别反复，节约开发资源，快速响应活动页变更迅速的场景…

期望搭建一个能快速搭建广告页的平台，开发/运维人员只需要维护 或 开发新模板就好。

1.2 技术选型

​ 出于浏览器兼容性考虑起初打算使用vue2，但是vue2的局限性太大，经过初步的设想，vue2虽然也可以实现，但是其实现的代码会比较“难看”，此项目包含比较多的逻辑交互，以及组件之间的变动后，实时性的响应，如果完全依靠vuex，可读性也会比较差。由于此项目大部分是开发/运营等少部分使用，所以最终权衡下打算使用vue3进行开发。

1.3 面临的问题

1. 模板用什么形式开发？
2. 配置变动的时候预览要实时更新，如何做到？
3. 如何降低模板开发人员的开发模板成本？

1.4 设计构思

​ 初期主要实现 模板 -> 页面 的形式，开发者开发好模板，使用者直接可以通过模板+配置组装出不同的页面。

---

​ 直接了当的做法：一个模板就是一个组件。（比如一个head，就创建一个文件夹，包好index.vue 和 config.vue）

​ 问题: 重复开发率高，且对模板维护的开发人员不友好，还需要额外开发配置项。

---

​ 配置组件化的做法：把配置做成组件，模板开发人员简单引入就好。

​ 问题：不够统一，配置项由模板开发人员自由组装，不能保证同样的特性模板，可能让用户在配置上缺乏统一感。

---

​ 类浏览器设计：创建多个原子class，在设计上模拟 div容器、图片、文字、链接、轮播图等（从模板 ->页面 变成 原子元素 -> 模板->页面）。

​ 好处：符合开发者思维，并且将元组件的逻辑更好的复用起来，同时方便后期的更自由的扩展。

​ 问题：需要找寻继承关系，对初次开发可能需要花一些时间理解（但我感觉是值得的）。

---

​ 以上的设计中，类在被实例化的时候，会使用 reactive（this） 作为proxy对象返回，这样此对象就可以直接在页面进行渲染，自带响应式。其渲染效果和配置也使用jsx做成可重写式的函数式组件的设计，保证其可读和复用性。

​ compositionapi + jsx + 类浏览器的设计，使得前期准备工作比较久，但是成型后，后期开发非常迅速，并且可维护性和可扩展性较好。

​ 需要新添加的功能，给原子元素添加对应属性即可，需要增加新的原子组件，继承上基类，很多逻辑可直接复用，只用编写当前原子组件特有逻辑即可。

​ 至于其他需要跨组件维护的值，创建一个控制中心的静态类（此处的控制逻辑不复杂，暂时只设计为一个类，后期有需要可进一步拆分【比如页面管理、模板列表、用户操作控制等】），里面存放一些 reactive、watch等对象和公共方法（获取源码、保存配置等），就能让所有地方共享这些通用逻辑，需要响应渲染的值，也无需层层传递，因为其本身就是一个proxy的值，直接使用，一旦修改，所有地方自动更新。

​

​ 这样应对之前的问题：

1. 直接使用设计好的原子元素组件组成模板，css和js与以前的开发方式一致。
2. 使用class+compositionapi+jsx 的形式，对getcomponent方法进行get方法重写，这样每一次get被调用，就知道需要更新，script需要重新执行
3. 目前设计可让开发人员使用原子组件构成，就像使用div、text、a标签一样，后续可加入ast语法解析，从编写js => jsx

1.5 未来设想

1. 突破模板限制，直接使用原子元素 --> 页面 的形式，解放更多的开发资源。
2. 支持PC端广告页的制作。
3. 支持源码导出后可再次导入。
4. 尝试支持vue项目的在线编辑。

2 vue3开发的设想

2.1 vue带来的自由

​ 记得以前，想使用面向对象的设计 或 把一些公共逻辑抽离，也需要把逻辑和视图分离，逻辑和视图的结合需要通过data或者 写 jsx，并且可能很多需要对vue对象的操作，也无法进行，除外把此对象暴露出去。

​ 使用vue3开发之后，compositionApi会帮你打破了这层束缚，不再把你限制在一个模板的框框里。

​ 你可以把你脑海中的构思，抽离未一个类/函数，甚至变量，并且他是带有响应式、可直接在页面使用的值，这给我们打下了自由的基础。

2.2 设计 ≠ 把逻辑拆出去

​ 起初我对vue3的态度是，可以把逻辑拆出去了，结合compositionapi，可以直接把响应式的数据传递回来，这样逻辑共用了，页面看起来就比较简单，交互看起来会比较清晰（有哪些事件，页面所用到的方法等）

​ 但是这和使用vue2+把逻辑拆除去起始区别不大，除了能传递一个响应式的数据对象。

​ 于是想想他们之间还能擦出怎样的火花，在开发编辑器的过程中，发现只要你设计比较得当，他的compositionapi可以让你的开发体验很舒适（具体可见后续说明）。

2.3 对开发者的要求

​ 自由，代表着对使用者更高的要求。

​ 以前使用vue2，你可能只用划分 head、main、dialog、看起来比较通用的组件等等，等后续业务更新的时候，增加一个页面，就加一个vue，依次类推，时间长了，发现好多冗余代码，且大大小小的迭代，让代码维护性越来越差。

其实在编辑器的开发之前，做过很多的准备和构思，并且此项目的需求评审，甚至业务背景和未来几个版本内发展，都十分清楚。这给我进行设计提供了很好的基础。所有，你想使用vue3设计出比较满意的结构，我认为前提是你充分了解了你当前在做的项目，从背景和未来发展都要有一些概念，才能更好的设计。

​ 类似后端一样，需要对业务了解更清楚，数据库、Class设计 和 项目架构才能更加合理，所以如果你对你所做的项目不太了解，只是跟着需求做页面，那我建议你暂时不要尝试使用vue3去设计，先了解你手头的项目。

2.4 更多的可能性

​ 不同的项目用vue3开发的设计必然不同，不过这次编辑器的开发，有体会到了vue3的快乐。

​ 目前一些个人的看法，如果你有过react的开发体验，应该更能有这些感受。

1. 简单项目：无需过度设计，正常使用，与vue2使用体验相差不大。

2. 常规业务项目：你可以尝试抽离出一些类/静态类，把项目中常用的状态和数据分布在这些类的属性中。（其实就是作为vuex使用，不过结合了你的一些设计，让你的代码更有可读性）

3. 逻辑复杂的业务项目：建议一定要抽离class的概念，把你能预见的业务场景，尽量的通过面向对象的设计，让他们初期就拥有较好的可读性和扩展性，存在比较通用的小组件逻辑，可以结合jsx抽离成函数式组件。

   主要需要多尝试 和 多思考，无论你主要使用的是react还是vue。
   根据尤大的计划，后续 vue2.7以及之后的版本，也会支持compositionapi，意味着vue2.x的项目可小成本升级到支持compositionapi，个人感觉使用vue模板思维一战到底的思维会逐渐被替代。

3 结语

有好的想法和经验，欢迎大家多多交流。