此页面需要javascript支持,请在浏览器中启用javascript

复盘-当年系统设计选型

缺陷
复盘
技术选型
阅读 

前言

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

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

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

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

就像 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 timeruntime time 的依赖了, 这点 buildModulesmodules 没有解决最本质的问题。

这个问题是什么呢?

  • 部署 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 , 那时候还是 wepympvue 的时代,不像现在,完全就是 uni-apptaro

本来是要用 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/core7 个月没更新了。

还是非常感谢 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 哈哈。

通读一遍

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

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

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

© 2021 icebreaker 苏ICP备19002675号-2
version:1.2.2