VUE3开发实践 - 前端静态页编辑器
前言:记录一次使用 vue3开发 前端静态页编辑器 的历程,包括对项目的设计构思 和 对 vue3开发的一些思考,希望可以和大家多多交流讨论。
之前也做过 react的开发,所以很多思维在这里运用到,但是相较于react,vue3开发起来会会让人感觉是一种有尺度的自由。
由于项目为公司内项目,会更多讲述技术性的内容。
主要分两方面进行介绍:
1:前端静态页面编辑器(部分偏业务的内容会删减,更多是站在项目和vue3角度下的思考)
2:不同项目/业务场景使用vue3开发的一些设计、构思
1.前端静态页面编辑器
1.1 项目背景
大多数活动页的布局大同小异、十分相似 ,很多时候开发做了重复的工作,并且修改、发版、测试等工作,还特别反复,节约开发资源,快速响应活动页变更迅速的场景…
期望搭建一个能快速搭建广告页的平台,开发/运维人员只需要维护 或 开发新模板就好。
1.2 技术选型
出于浏览器兼容性考虑起初打算使用vue2,但是vue2的局限性太大,经过初步的设想,vue2虽然也可以实现,但是其实现的代码会比较“难看”,此项目包含比较多的逻辑交互,以及组件之间的变动后,实时性的响应,如果完全依靠vuex,可读性也会比较差。由于此项目大部分是开发/运营等少部分使用,所以最终权衡下打算使用vue3进行开发。
1.3 面临的问题
- 模板用什么形式开发?
- 配置变动的时候预览要实时更新,如何做到?
- 如何降低模板开发人员的开发模板成本?
1.4 设计构思
初期主要实现 模板 -> 页面 的形式,开发者开发好模板,使用者直接可以通过模板+配置组装出不同的页面。
直接了当的做法:一个模板就是一个组件。(比如一个head,就创建一个文件夹,包好index.vue 和 config.vue)
问题: 重复开发率高,且对模板维护的开发人员不友好,还需要额外开发配置项。
配置组件化的做法:把配置做成组件,模板开发人员简单引入就好。
问题:不够统一,配置项由模板开发人员自由组装,不能保证同样的特性模板,可能让用户在配置上缺乏统一感。
类浏览器设计:创建多个原子class,在设计上模拟 div容器、图片、文字、链接、轮播图等(从模板 ->页面 变成 原子元素 -> 模板->页面)。
好处:符合开发者思维,并且将元组件的逻辑更好的复用起来,同时方便后期的更自由的扩展。
问题:需要找寻继承关系,对初次开发可能需要花一些时间理解(但我感觉是值得的)。
以上的设计中,类在被实例化的时候,会使用 reactive(this) 作为proxy对象返回,这样此对象就可以直接在页面进行渲染,自带响应式。其渲染效果和配置也使用jsx做成可重写式的函数式组件的设计,保证其可读和复用性。
compositionapi + jsx + 类浏览器的设计,使得前期准备工作比较久,但是成型后,后期开发非常迅速,并且可维护性和可扩展性较好。
需要新添加的功能,给原子元素添加对应属性即可,需要增加新的原子组件,继承上基类,很多逻辑可直接复用,只用编写当前原子组件特有逻辑即可。
至于其他需要跨组件维护的值,创建一个控制中心的静态类(此处的控制逻辑不复杂,暂时只设计为一个类,后期有需要可进一步拆分【比如页面管理、模板列表、用户操作控制等】),里面存放一些 reactive、watch等对象和公共方法(获取源码、保存配置等),就能让所有地方共享这些通用逻辑,需要响应渲染的值,也无需层层传递,因为其本身就是一个proxy的值,直接使用,一旦修改,所有地方自动更新。
这样应对之前的问题:
- 直接使用设计好的原子元素组件组成模板,css和js与以前的开发方式一致。
- 使用class+compositionapi+jsx 的形式,对getcomponent方法进行get方法重写,这样每一次get被调用,就知道需要更新,script需要重新执行
- 目前设计可让开发人员使用原子组件构成,就像使用div、text、a标签一样,后续可加入ast语法解析,从编写js => jsx
1.5 未来设想
- 突破模板限制,直接使用原子元素 --> 页面 的形式,解放更多的开发资源。
- 支持PC端广告页的制作。
- 支持源码导出后可再次导入。
- 尝试支持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的开发体验,应该更能有这些感受。
-
简单项目:无需过度设计,正常使用,与vue2使用体验相差不大。
-
常规业务项目:你可以尝试抽离出一些类/静态类,把项目中常用的状态和数据分布在这些类的属性中。(其实就是作为vuex使用,不过结合了你的一些设计,让你的代码更有可读性)
-
逻辑复杂的业务项目:建议一定要抽离class的概念,把你能预见的业务场景,尽量的通过面向对象的设计,让他们初期就拥有较好的可读性和扩展性,存在比较通用的小组件逻辑,可以结合jsx抽离成函数式组件。
主要需要多尝试 和 多思考,无论你主要使用的是react还是vue。
根据尤大的计划,后续 vue2.7以及之后的版本,也会支持compositionapi,意味着vue2.x的项目可小成本升级到支持compositionapi,个人感觉使用vue模板思维一战到底的思维会逐渐被替代。
3 结语
有好的想法和经验,欢迎大家多多交流。