实用的VUE技术系列——从源头讲起（vue 好在哪）

用户7413032

发布于 2024-03-12 11:56:39

18900

代码可运行

文章被收录于专栏：佛曰不可说丶佛曰不可说丶

运行总次数：0

代码可运行

声明：本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！

从源头讲起

vue作为当之无愧的前端流量之王，大家都在讨论，钻研，学习，膜拜。当然，我也是一个，

然而当我如痴如醉的把玩vue的时候，却发现我陷入了一个误区。

我始终没有真正的明白，我们为什么要学习他?

我叹服他的技术，钻研他的原理，整理他的源码，理解他的思想，

然后某个五百人的wx群，三百人的qq群，或者求职者云集的面试的现场，抛出，诸如 diff算法、依赖收集 、编译原理 这种高深莫测的技术话题和技术见解

霎时间只见众人顶礼膜拜，偷来花痴的一瞥，左一句大佬，右一句大佬，听的我心花怒放，日见嚣张。

我总以为作为技术人，技术就应该是一切，我要变强，变得能看懂所有源码。要以装逼秀肌肉为己任。

别人写的代码乱，我抨击他太low ，别人代码写的太长，我教训他太菜，别人代码用了react ，我蔑视的说那是个垃圾（其实是我不懂）

我好为人师，我倚老卖老，我自以为是，或没事找事

我每天都在各种可以发挥我独到见解的地方炫技。仿佛有着众人皆醉我独醒的即视感。

就这样，装了几年，工资没涨，行情没好，在鲜花和掌声背后的我，也自然而然的没成为所谓的大佬

因为我发现，所谓的技术炫技 ，在业务面前狗屁不是！

我相信你一定经历过，在一个夜深人静的夜晚，看着被改了无数遍的业务屎山代码,心中涌出了一个大胆的想法： md，有一个能跑就行（要不我跑，要不代码跑） 。

在我们大多数的工作中，这才是我们面对的现实，赤裸裸的现实！

至于什么diff算法，最长递归子序列，你爱啥序列啥序列，能给我快速解决问题，他就是好序列！

然后用十个if esle外加三个for循环 粗暴的解决问题

纪伯伦说过，我们已经走的太远，以至于我们忘记了为什么而出发

是的，我们仿佛真的忘记了，当初为什么要学习vue 。

是啊，为什么要学vue？这是一个多么朴实的问题。

有人说，是单位项目需要，有人说是面试要考，还有人说是，火爆的框架就要学

其实，要解答这个为什么？我想要我的职业经历说起

想起刚入行的时候，从原生js 学起 然后jqery 崛起，开始jqery一把梭哈，然后发现 angular、react 崛起

接着，vue 杀出一条血路，受各个小厂的喜爱 ，angular由于彻底升级，拉伤大腿，也彻底的在中国失去市场。

这一路走来，脑海中的一幕幕浮现在眼前，恍如隔世，又恍如隔日！

入行七八年了，vue 也陪伴我五六年了

vue为什么能迅速火爆大江南北，为什么能够从一个小小的框架成为一个行业的标准之一

原因很简单， 又快又好的解决问题

当别人还在考虑怎么设计项目架构的时候，我靠着vue提供的脚手架，已经完成了项目搭建

当别人还在抽象代码的时候，我已经靠着vue 的组件系统，完成了多页面开发

当别人还在半夜猛敲键盘改bug的时候，我靠着vue的能力早已经改完bug 躺在床上刷着抖音

所以，好用 才是我们选择vue的本质原因，毕竟，懒是人类的本性，能又快又好又省事的搞定开发任务，何乐而不为呢？

而炫技,只是他的一个附加属性，我们要很清楚的确定一个目标，理解原理，是为了让我们排查问题，解决问题，而不是炫技，如此而已!

此时此刻，我们需要明白的是，我们对于框架的学习，要以实用为主，提升自己的方向当然也要以学以致用为主

在正式的开始讲实用的vue之前，我还有的两个疑问，与各位仁兄讨论!

我到底应该选择拥抱vue还是react

vue 和react 之争，已经持续了很多年，并且还会持续很多年，因为有人的地方就会有江湖，码农的江湖虽然没有人会永远年轻，但总会有人年轻。

于是该骂街的还要继续骂，该吵架的还要继续吵，该站队的还要继续站

几年来，争论不休，并且正反方的最佳辩手也是总是能引经据典，在最刁钻的地方，找个最刁钻的角度，给出致命一击

虽然头几年我也是骂街大军中的一员，但是自从颈椎出问题以后就不这个那个都研究了

而到了今天大家争论哪个框架更好，我已经开始叩谢祖师爷赏饭吃了

我偷偷总结了，正方（支持vue）反方（支持react）最佳辩手，的辩论稿

正方

先阐述vue 的伟大之处，旁征博引，甚至更有甚者，搬出vue祖师爷的经典名句react就是性能差点

vue优点如下：

1、尽可能的降低前端开发的门槛
2、局部更新，优秀的性能
3、符合html标准的模板语法，符合传统的编码习惯
4、规矩足够多，代码可读性好，
5、模板语法可以，支持静态编译

这几点也是vue的核心竞争力，特别是第一点（我总是感谢祖师爷赏饭吃），当然，这些反方是不会说的，

他们会说的是，ts支持一坨屎 ,写法固定且呆板, api设计难用，等等。。。

反方

react 就不用说了，一个跨时代的UI开发新思路，不需要迎合用户，写法足够炫酷，灵活，随心所欲，总之VUE垃圾

react 优点如下:

1、友好拥抱ts 2、灵活开放的开发体验，随心所欲写代码 3、纯函数的编程范式，够先进，b格够高

当然，到了正方的嘴里，就开始抨击他，性能不好，jsx难用云云。。。

好了，正方反方总结完了，下面我说结论：

虽然听着都很有道理，但都是吃饱了撑的

之所以大家不断的争论，不断的吵架，骂街，主要就是为了证明一个事情，我比你牛逼!!!

但牛逼这个事情，哪有个准？所谓三十年河东三十年河西，今天你牛逼，明天就有可能菜逼

所以，最后又回到我们之前的论点上来，我们使用这些技术的初衷又是什么？

又快又好的解决问题

对，围绕着这个初衷，单位用什么你就用什么？单位的基础设施是哪个方向的，你就干哪个方向的，当你在一个方向上有所建树的时候，什么框架牛逼，都不如你牛逼好使

有jy又问了，如果单位没规定用啥呢?

那你想用什么就用什么，不过，那个？我想问下这种可以自己技术选型不受束缚的神仙公司还招人吗？

能看懂VUE源码到底是不是高人一等

接下来我们探讨下第二个问题，能看懂VUE源码真的就高人一等吗?

这个问题一直困扰了我很久，因为在业界的共同认知中，能看懂源码的人，一定是个很强的人，

但是，我平时在业务开发的过程中，不能说是跟源码没什么关系，简直可以说毫不相干

那么阅读源码真的可以变成个很厉害的人吗？

于是几年前，我抱着变成一个强人的态度，试着硬着头皮读了读vue的源码？

在我之前的认知中，阅读源码是个很高深的能力，他需要你有很高的知识储备，以及有着缜密的思维能力，要能够理解作者的想法，体会作者的用意，甚至要跟他产生共鸣！

我这种整天crud 的混子能看懂吗？

随着几天的深入的研究，我发现我竟然看懂了。

原因很简单，他就跟学习一样，只要你硬着头皮看，就能看懂，不懂的地方，就百度。

我恍然大悟，原来所谓的源码，也不是离我那么遥远！

我甚至还做了笔记和总结github如下：vue-next-analysis

然而三年过去了，我变成大佬了吗?

并没有，别说大佬了，老大都没当上过，入行七八年，依然是一线的小兵！

这究竟是为什么呢？

我苦思冥想，业界不是公认能看懂源码就一定很强吗？我怎么好像感觉屁用没有

就在前几天，就一个同事问了我一个问题

nextTick和onUpdated，究竟谁先执行？

我竟然回答不出来一个字，我明明看过源码啊，我通读了啊，当时明明研究过这个问题啊，还深入探究过执行过程啊，怎么就回答不出来呢？

原因很简单，我用不上，就会忘！

我恍然大悟，原来，所谓的能看懂源码，只是能看懂，并不是能运用，即使理解了，随着时间的推移，也有可能忘记。

所以，能看懂源码，只是你有毅力，而并不是你有能力

这是我多年陷入的误区，我相信这也是很多人的误区

能看懂源码并没有什么卵用，有用的是你能从源码中收获什么？

于是我重新翻出了 vue的源码

我发现我之前只顾着炫技 追求高大上的东西反而遗漏了很多实用且不起眼的气细节

我才明白，当年高人一等的优越感，是多么的荒诞可笑

学以致用 这四个字，真的是需要自己仔细的琢磨和体会！

例如：

vue中有着完整的且经过验证的工具函数，根本不需要我们百度

// 是不是数组
export const isArray = Array.isArray
// 是不是map
export const isMap = (val: unknown): val is Map<any, any> =>
  toTypeString(val) === '[object Map]'
  // 是不是set
export const isSet = (val: unknown): val is Set<any> =>
  toTypeString(val) === '[object Set]'
// 是不是日期
export const isDate = (val: unknown): val is Date =>
  toTypeString(val) === '[object Date]'
  // 是不是正则
export const isRegExp = (val: unknown): val is RegExp =>
  toTypeString(val) === '[object RegExp]'
  // 是不是函数
export const isFunction = (val: unknown): val is Function =>
  typeof val === 'function'
  // 是不是字符串
export const isString = (val: unknown): val is string => typeof val === 'string'
// 是不是symbol
export const isSymbol = (val: unknown): val is symbol => typeof val === 'symbol'
// 是不是对象
export const isObject = (val: unknown): val is Record<any, any> =>
  val !== null && typeof val === 'object'
// 是不是promise
export const isPromise = <T = any>(val: unknown): val is Promise<T> => {
  return (
    (isObject(val) || isFunction(val)) &&
    isFunction((val as any).then) &&
    isFunction((val as any).catch)
  )
}

再比如: vue源码中提供了完整的monmrepo构建方式，也值得我们研究和借鉴，而不是去关注代码本身

还比如：

vue源码中提供了pnpm 这种先进的包管理方式，让你再也不用为了下不了node-sass耽误开发进度，而口吐芬芳

所以，源码中的很多细节都足够我们去达到学以致用的目的，而不是，在哪疯狂研究什么叫最长递归子序列，研究明白它的原理，我相信并不能让你更快的去完成需求

所以，我的结论很简单，懂不懂的不用要，完成业务很重要

我们的技术学习要以务实为主，借鉴源码的方案，解决业务中的问题，这才是最后的终极之道

哪有人又问了，这玩意面试要考啊？

你怎么能说不重要呢？

请注意，在面试中要考的是原理，并不是源码，

其实面试之所以要考，是市场的供需关系决定的，市场人太多了，他需要有手段去筛选掉一部分人，比如，按照学历筛选，按照长相筛选，当然也可以按照原理筛选

虽然这种筛选方式并不怎么公平，可在有限的时间内，面试官能问你什么呢？

他总不能跟你聊理想吧