使用 Vue3 编写个管理后台

前言

随着 Vue3 版本发布日渐成熟，Vue-Router 和 Vuex 从几个月的前的 Beta 版本迎来最近的正式版，再加上明年公司产品升级需要，最近开始尝试自己编写一套管理系统。虽然看起来和 Vue2 最火热的花衩裤的管理系统差不多，主要公司前端的管理系统都用到 vue-element-admin 模板，考虑平滑过渡升级，所以我在 Vue3 制作的模板保留以前的风格，使用起来完全没有陌生感。

Vue3 对比 Vue2 看起来改动并不是很大，至少兼容 Vue2 的写法，除了底层使用 Proxy 方法来驱动数据响应之外，还对 TypeScript （下列简称 TS）支持更好，关于 TS 我有几点想法：我对 TS 态度并不怎么拥护 ，所以在编写 Vue3 模板并没有使用上 TS 语法。之前体验上手之后觉得 TS 的缺点大于优点，虽然使用 TS 可以大大提高项目的健壮性以及可维护性：

• 但是对开发人员不仅仅是提高学习门槛，更多降低工作效率，难以想象要花多少时间去排除其中各种奇葩的问题，然而我发现引发这些问题都是一些浏览器的 Api 导致的奇怪的问题。 当然我觉得在 Node 后端上使用 TS 体验是非常棒的，毕竟之前写过几例 Nest.js 项目。
• TS 会限制你的想象力，为什么说 JavaScript 是世界上最流行的编程语言，那是因为它的优点：灵活性，正是因为灵活性的存在，使得前端生态各种花里胡哨。如果 TS 来限制 JS的灵活性，虽然解决了 JS 因灵活性带来致命的问题，但我失去了 JS 本身的灵活性意义，所以对此不可取。既然这样为什么不基于 TS 开发个浏览器引擎呢？

组合式 API

在 Vue3 主要推荐是组合式 Api 编写组件，如果你对该模式不熟悉也可以用 Vue2 的方式编写项目。虽然官方文档没有说到推荐哪种方式编写，但个人体验一段时间后发现还是使用 Composition Api 更好，因为可以提高代码的复用性，虽然 Vue2 的 mixins 也能做到复用性，但因为他是直接引入会导致复用代码块污染，导致其他页面出现因为变量污染一些问题，然而 Composition Api 很好解决这些问题。甚至利用 Composition Api 写出的代码对比以前更加灵活，几乎没有什么限制。