Vue CMS 的产品形态

回顾完历史,我们来看看业务需求。

看过我上一次 Chat 《升级工具链吧!使用 Webpack 开发企业官网》的同学应该知道,一切都源自我厂的官网要改版。

我厂官网 v1.0 采用的是前文中“远古时期”的模式,由设计师设计、制作完网页之后,直接把纯静态资源上传到服务器,然后提供服务。这样的好处是:

  1. 简单好操作,对人员要求低
  2. 访问速度快,对机器配置要求低
  3. 对搜索引擎友好

但是也有很多不足:

  1. 纯静态,不利于调整内容
  2. 不利于 i18n,没有多语言版

这些问题,我在 v2.0 时进行了修正。首先,我引入 Gulp 做批处理,增加了“发布”环节,虽然最终还是部署纯静态内容,但是内容可以简单调整,也通过 DOM 查找,实现了 i18n,同步提供中英两个语言。

新版本上线一年半,效果不错,但也有很多不足:

  1. 需要开发者手动管理所有资源,很累
  2. 发布脚本很多很复杂,不便于理解;Gulp 采用 stream 模式,没搞过的新人很难接手
  3. 没有好的开发环境

于是,当整个页面内容都要更新时,我决定升级到 v3.0。这次使用 Webpack 工具链,采用多页面模式,配合 Pug 的可编程特性,更好的实现了最终效果,还可以配合 webpack-dev-server 方便的在本地开发。新版本大大改善了开发效率。新同事打开项目看了看 Webpack 的配置文件,很快就搞明白它是怎么工作的,如果要做工作,应该从哪里入手。

不过正如《矛盾论》所说,当主要矛盾被解决,次要矛盾就会变成新的主要矛盾。此刻,新的问题出现:专业的前端开发能很快摸清项目结构,但对于后端同事来说,未知的新概念还是很多。教会他们理解所有框架、类库、工具没什么意义,如果能够给他们一个简单可操作的 UI,那才能真正提高效率。比如 npm run edit,然后浏览器就打开一个页面。他们按需编辑后,保存,提交仓库,发布。这样的流程才是真正要追求的流程。

所以,最合适的做法就是用 Vue 实现一些编辑器组件,它们有两种形态:编辑,静态。编辑态就不用解释了;我们只要把静态的 HTML 保存下来,生成静态页,即可。

好的,现在需求已经出来了:

  1. 已有一个 Vue 项目
  2. 这个项目大部分功能由 SPA 提供,不需要静态化,不需要预渲染
  3. 这个项目部分路由需要生成静态页
  4. 部署的时候,只需要部署静态页和其引用的资源

看到这个需求,我想大多数关注前端的同学可能跟我一样,第一反应就是:应该找一个 SSR 框架,添加到现有项目中。那么,就选最出名的 Nuxt.js 吧,这个框架的作者还跟 Vue 的作者一起看 NBA 呢。

results matching ""

    No results matching ""