/vue2-scaffold

The best scaffold for Vue 2.x based on vue-cli#vuejs-templates/webpack

Primary LanguageJavaScript

Vue2 脚手架

Vue Demoissues 中,最常问的就是有没有升级 Vue 2.x 的计划
说实话,一直以来我都对 Vue 2.x “跪舔” React 嗤之以鼻,因此之前我并没有打算折腾

Vue 2.x 阉割掉了很多相当有用的特性,还动不动就扯“状态管理”
的确是让我大失所望,因此这几个月以来我都是坚守 Vue 1.x

有关这个问题,不妨看看 Vue.js 官方示例:
Markdown Editor Example 1.x 版本 | 2.x 版本
相信您会更加直观地体会到 Vue 1.x 的魅力所在

各大论坛上看到很多刚入门的新童鞋在人云亦云的情况下捣弄 Flux / Redux / Vuex
就像是拿着屠龙刀切水果,这在一定程度上,是使用者比较累,且水果也未必切得好看

当然,比起 React 社区,Vue 的全家桶已经是相当轻量
尤其是看到了 MobX 的盛行,更让我意识到组件化状态自包含才是正道
谈及全局状态管理,在实际项目中我更倾向于使用 根组件 或者 URL

URL 本身就是一个全局的状态容器,详见 Vue Demo 文档:URL 是单页应用的精华

让我着手折腾 Vue2 脚手架的,是最近的一次独立组件重构经历


在重构 DataTable 组件的过程中,我守旧的观念开始发生转变
尤其是通过 .sync 传递的 props 层数越深,就觉得越发不可控
当然,如果是按照之前的思路,使用根组件来存储共用的状态
子孙组件直接使用 $root $parent 获取与修改数据,也是完全可行的,但这并非最佳实践
而在独立封装的组件中引入 Vuex 又并不合适(详见 滴滴 webapp 5.0 Vue 2.0 重构经验分享 第 2 点)
因此只能另辟蹊径...

经过一番查阅,我了解到一种另类的状态管理思路,并整理到了这里
原理很简单,就是通过 “闭包 + 共享 data 的方式实现阉割版的 Vuex
这让我初步尝到了统一状态管理的甜头,也理解究竟什么时候才该用统一的状态管理

虽然我写出了 Redux 简明教程,但我从未在实际项目中用过
皆因我不见得究竟是多大的项目才需要用到这种繁冗的状态管理
(除非您需要如 You Might Not Need Redux 文中提到的使用 Redux 的优势)
我更倾向于后端流行的微服务模式,一个大的项目可以拆分成若干个子项目
而对于前端而言也该是如此:各组件内部状态自维护,使用与卸载无副作用,不掺杂全局,分而治之
(上面的 滴滴 webapp 5.0 Vue 2.0 重构经验分享 第 1 点也有相关的拆分讨论)

既然已经折腾出另类的组件内部的状态管理方式,而且 Vue 2.x 又已大势所趋,那就折腾吧!


扯了那么多,该说说这个 Vue2 脚手架和之前 Vue Demo 的差别了
总体而言,差异很小,基本上就是把 Vue 1.x 的语法换成 Vue 2.x
因此升级的代价相当小,文档完全照搬 Vue Demo 的文档
对于新用户,强烈建议先通览文档后,再使用该脚手架进行开发

开发前请通读 Vue 2.x 文档vue-router 2.x 文档,尤其是 从 Vue 1.x 迁移 一章


最后说说为什么不使用官方的 vue-cli,而自己折腾一套脚手架
首先不得不承认,这是参考自官方的 vuejs-templates/webpack 模板
改造初衷是这套官方模板与 Vue.js 的优雅哲学格格不入,一看它的 build/ 目录基本上就不想用了
官方意欲极力避免用户折腾配置(开箱即用),特意另开了 config/,但这就使得配置项变得更加不直观

但无论如何,用户得学会自己走路,自己踩坑,自己折腾,你只需要提供一个直观的高可拓展性的脚手架即可
我所能做的,就是极力提供一目了然的 Webpack 配置目录与常规的 package.json
之后就让用户按需折腾,而不是一上来就把一条龙的测试框架都堆上来

当然,vue-cli 并不是一无是处,使用它的 vue build 来快速开发独立组件还是相当爽快的
(上面提到的 Vue 另类状态管理 就用到了 vue build


最后的最后,祝您玩得愉快吧!