复盘-当年系统设计选型

前言

本篇文章极其的主观，只代表作者个人观点。

一个时代有一个时代的历史局限性，技术选型也是如此。

这几年做前端下来，感觉这方面的技术一直在飞速的发展。

开发也越来越简便，这是一个好现象。

就像 vue 的出现一样 ，大大降低了前端入门的门槛
使得一个程序员，不需要多少的训练，也可以实现复杂且高性能的页面
当然这其中一部分也靠浏览器技术的不断的进步

而 小程序，RN , ionic , flutter 的出现，又给了前端更多的可能性

firebase 这种 BaaS ，还有 openFaas based 的出现 ，又大大的减少了开发的成本。

No Code / Low Code 更是一条非常值得探索的路

然而，这也似乎让技术，让程序员显得更加的廉价。

这是最好的时代，这是最坏的时代。 我们程序员天生内卷，喜欢自我革命。

技术长河有幸浅尝

我从 2018 年开始，主写前端。

Vue 相关

那时候技术选择 vue 是毋庸置疑的。毕竟生态好，入门也简单。
vue 2.x 那时候就发布了，不过那时 @vue/cli 还不成熟
很多的webpack配置还是裸露在外的。

webpack 当年也是 3.x 版本，后来升级到 4.x 之后，大量的插件和 loader 都要升级
很多插件都废弃了，要更换其他的实现。

ps: 现在 webpack 已经到 5 了，前几天发现官方维护的 loader 大量更新，做了很多的 Breaking changes , 马上就要不兼容 4.x 版本了 -- 2021/2/7

webpack 升级的成本，随着 @vue/cli 3.x 版本的发布，降低很多，因为从 3 开始，cli 就把 webpack 的配置，藏在了自己里面。当然现在版本已经是 4.x 了。

个人对 webpack 理解不深，之前有些场景，写了个粗糙的 plugin ，后来发现有更简单的实现，就废弃了。

就 vue 本身去实现之前的复杂的逻辑来说是简单的。

拆了很多的组件，总会遇到的 父子孙兄弟 通讯问题，尝试了很多的方案。

• prop/emit (默认)
• vuex (没必要)
• ref (看场景)
• 主控 + 引用传递 (这种做法比较偷懒)
• bus (可维护性差，只有部分场景适合)
• inject/provide (极不推荐)
• mini-store + reducer + mapper (用下来这种做法，代码量少，质量最高，不容易出 bug)

最后那种方案，是写了 2 年多的一个经验小总结吧。用一个比喻来说，像一根针，把不同的组件随意串联，state 随意产生，随意的销毁重置。

以后肯定会想到更好的方案，3.x 版本肯定会有的。

Nuxt 相关

Nuxt 从 2.x 开始的，vue ssr 一个便捷的选择，坑很多。

不过，当我们自己能够区分 ，哪些代码运行在 process.client ，哪些运行在 process.server 就好很多

另外要深刻认识的，就是 服务端渲染，客户端激活 , 这是和传统的服务端渲染，最大的不同之处。

另外假如你对我上述 2 个问题都有理解，那你就会对我下面写的这一段代码，会心一笑了。

// *.vue || `store/vuex`
let windowBased
if (process.client) {
  windowBased = require('i-need-window-otherwise-boom') //.default
}
// or ES2020 import() promise

引入很多 spa 下的 vue 组件同理

当然这一段还是在 Nuxt 内部的 ， 外面还套着一个 server 的壳
Nuxt 里面还搞了个 connect 来处理 server middleware

这很容易让人产生一个 中间件迷惑 问题 ，nuxt 内部不看源码就是一个黑箱，不知道是否应该 next()

• express
  • router
  • nuxt
    • connect
      • express
      • function middleware
      • router
  • router
  • error handler

当然 Nuxt , 达到了使用时 seo 的目的，基于 页面/组件/数据 的 3 级缓存，在大部分时候也很实用。

除此之外，由于这是一个 nodejs 项目，能做很多 spa 做不到的事情，在此不再叙述。

写到这，又想到了一个可以吐槽的点，就是 compile time 和 runtime time 的依赖了， 这点 buildModules 和 modules 没有解决最本质的问题。

这个问题是什么呢？

• 部署 nodejs 项目，为什么需要整个 node_modules 也上去？
• 部署 spa 前端项目，为什么只要把打包好的 dist 放进 nginx/cdn 上

Nuxt client bundle 可以分离，server bundle 中是否有代码直接依赖 node builtin or node_modules ?

打包成 layer 是否会包含很多不必要的 compile time 的包？

想必看到这里，这个问题的呼之欲出。有什么好的解决方案，希望能留下评论或者直接联系我。

小程序 相关

我从 native 写到了 wepy 又写到了 uni-app

2018 年年末那个时代 ，原生 npm 构建还没出，原生还得写 5 个文件 wxml/wxs/wxss/js/json 切来切去很烦，api 还是回调也很烦，this 指来指去的

用原生写完一个之后，立马就使用了 wepy , 那时候还是 wepy 和 mpvue 的时代，不像现在，完全就是 uni-app 和 taro

本来是要用 mpvue 后来发现 mt 这伙人对这个项目不上心，bug 一大堆。后来就使用了 wepy 1.x

Wepy 1.X

wepy 1.x 版本，优点很多，实际用下来也有少许不足，但是瑕不掩瑜。

优点:

• npm 支持
• scss (原生当时不支持)
• babel
• Promisify
• 请求列队，事件优化

个人认为的缺点:

• 自定义组件化不彻底，一个组件多次使用需要使用 <repeat> or 多次声明不同的组件 id
• 一些全局的配置没有暴露，比如实现一个全局默认分享，就要改原型:

wepy.page.prototype.onShareAppMessage = function onShareAppMessage(params) {
  return {
    title: 'Hello world',
    path: '/pages/login',
    imageUrl: '/images/shared.png'
  }
}

• class 写法个人不喜欢
• config 这部分会被转化为 json ，然而无法使用 js 进行动态配置。

现在 2.x 版本也出了 ， 不过很可惜作者个人力量也有限，刚刚看了一下 @wepy/core 也 7 个月没更新了。

还是非常感谢 gcaufy 大佬的，鄙人也用 wepy 开发过很多个小程序。

uni-app

mpvue 的继承者 ，HBuilderX 深度绑定的 framework

优点太多了，大技术团队出品，特别厉害！生态也好。

要说有啥要吐槽的话：

• uni 统计几天不登，就断了
• 插件市场，有些不提供 npm ，点击之后直接复制粘贴到项目里了，不方便版本管理
• 一些框架底层能力没有暴露，比如我有兼容企业微信的需求，要把 wx.qy 相关的 api promisify , 没啥法子，去拷贝的 Uni-app 源码做的，这样只为了保持和其他返回值的一致性，看我下面的代码，就懂了

async noop(){
  try {
    const [err , res] = await uni.xxxxx()
    // then 
    if (err) {
      throw new Error()
    } else {
      // res do xxx
    }
  } catch (error) {
    //xxxx
  }
}

用 uni-app 开发小程序 ，体验真的是好，组件化很舒服。

开发比较大的小程序的时候，还是要提前做好分包的，因为打出来的包要比原生都要大 (vendor.js)

uni 版 vuex 也用着很舒服 ，event bus 也用着很舒服

ide 像我这种用惯了 vscode 的来说 ，不是很舒服。

啥时候 ide 也支持 自动化测试 就好了，不要只支持 cli 哈哈。

通读一遍

写着写着，感觉就变成了流水账了，忘了一开始要写的是啥了。

写的太意识流了，大部分人都看不懂。

本文就是一篇自嗨的流水账。