vue2.7 尴尬的过渡版本
vue2.7 尴尬的过渡版本
这个版本太特殊了。值得讨论。本文章内容偏向于主观。
升级指南
综合态度
升级了。但是只能升级一点点。这是一个很尴尬的版本。
为什么要升级？
期望使用并享受 setup 组合式 api 带来的代码编写便利。
升级前的技术积累？
事实上，应该先学习 vue3 的技术，熟练使用 vue3 的最新语法糖和 setup 组合式 api 写法。然后才开始使用 vue2.7 的组合式 api。
尴尬
生态系统完全跟不上
有很多踩坑。最重要的一点是，vue2 时代的一揽子库，均跟不上 SFCs 的 <script setup> 语法糖。比如：
- 在 2.7 的
<script setup>中，无法使用 vuex 常用的辅助函数。 - 2.7 的
<script setup>无法使用 vue-router 的组合式 api。常用的后台管理系统根本不敢去升级路由版本，因为 api 改动过大。为了单纯的组合式 api 而对框架做升级根本不划算。 - 2.7 无法充分使用 vue-i18n 的组合式 api。v8 的是 vue2 的，v9 才提供了组合式 api，但是 v9 只面向与 vue3。
（备注 2.7 也可以使用 vue-i18n 提供的组合式 api，不过需要额外的库实现。）
自我阉割
有许多常用的功能丢了，没了，变差了。比如：
- this 实例的获取非常麻烦，还需要考虑生产环境能否访问。有的时候你还真的需要去访问 this 示例的。
- 2.7 的
<script setup>仅仅允许单一模块导出，不允许同时导出多个模块。这限定死了某些特殊的代码写法。
不能完全使用 vue3 的语法
2.7 事实上不能充分的发挥 vue3 的技术。凡是 vue3 更新了更好的语法糖，你都没有资格在 2.7 内使用。我经常写 vue3，然后再切换回 2.7，我是会会明显感受到限制。这会给我带来相当大的心智负担，我需要额外考虑，2.7 不能使用最新的语法糖。
目前涌现出来的 vue 代码编写风格选型？
事实上出现了多种多样的代码写法了，我们需要权衡利弊。
vue2.6 + export default {option} + js + vetur 还行
这是最传统的代码写法。由 vetur 提供 vue 的语言服务。还算可以。
该写法是大家所熟知的写法。大家都会写，都熟悉。上来就能写，并实现业务。
该写法在规模化的组件内，确实被诟病。这是选项式 api 本身的弊端。
vue2.7 + export default defineComponent({option}) + js + volar 推荐
这个写法以增量的形式，拓展了很多功能。又不至于因为 vue2.7 + <script setup> 的缘故导致部分语法不能使用。
vue2.7 + <script setup> + js + volar 坐牢
不做赘述。自我阉割，废物一个。垃圾玩意。
vue3 + <script setup> + ts + volar 做不到
很抱歉，客观来说我们做不到。我做得到，我们做不到。
旧项目本身的升级成本过大
项目体量巨大时，你升级和迁移都忙不过来的。你来不及全面重构。
仅新项目可用
仅仅只有全新的项目，我们才有资格说，使用全套的，全新的技术栈。
对开发团队的技术栈要求过高
不要小瞧了这个写法的变更。写代码的不只有前端同事，还有后端同事。我们根本无法保证全体开发同事能够看懂 vue3 的新语法，typescript 的类型语法。学这些技术要时间的，我们团队没有时间去学习这些颠覆性的技术。大家习惯旧版本的语法了，新语法改动挺大的，大家学不完。
诸多不确定性
对于我来说，我仅仅只是在后台内使用 vue3 技术栈。没有在移动端内使用该技术栈，更不清楚写一些移动端核心的依赖包能不能较好的兼容。
没有成熟的二开框架
我是没有找到一款成熟的，开箱即用的，文档丰富的后台二开框架。就算找到了，团队更换框架的成本也是付不起的。
总结
- 不要迷信组合式 api 能改变什么。
- 2.7 不配。