知乎live笔记05 不吹不黑聊聊前端框架

Posted 2021-04-05 程序员爱叨叨

尤雨溪大神的live

确实是大神，讲的方向很多，随意哪个方向都是值得深入研究的领域。逻辑清晰有条理，听完之后只会觉得有时候人和人的差距实在是大到无法想象。佩服。

live中给出了很多推荐的链接，要花一些时间去学习、理解相关的知识和内容。

划重点：

1. 理论上讲，服务端数据对于前端来说是不可变的，前端不能随意更改服务端数据，如果要更改，必须与服务端确认。所以将服务端数据放到store中是有些多此一举的。

2. 技术方案都是先有问题，再有思路，同时伴随着取舍。在选择衡量技术的时候，尽量去思考这个技术背后是在解决什么问题，它做了怎样的取舍。这样一方面可以帮助我们更好的理解和使用这些技术，也为以后哪天你遇到业务中的特殊情况，需要自己做方案的时候打好基础。

3. 对于前端框架的学习，理解思想最重要，熟悉源码是为了提升与业务无关的工程化的理解等，对自己写框架、做方案有帮助。

---

标题： 不吹不黑聊聊前端框架

主讲人：尤雨溪

链接：https://www.zhihu.com/lives/846356429794336768

笔记内容：

Vue源码学习

Vue2.1.7源码学习

（http://hcysun.me/2017/03/03/Vue%E6%BA%90%E7%A0%81%E5%AD%A6%E4%B9%A0/）

组件化

组件分为：

1. 纯展示型组件

2. 接入型组件container，包含与数据源打交道的逻辑，将数据传给纯展示型组件

3. 交互型组件，比如表单组件，强调复用性

4. 功能型组件，例如<router-view><transition>，作为一种扩展、抽象机制存在

JSX与模板

JSX在实现功能型组件时是远超与模板的

模板更善于实现纯展示型组件，更容易书写样式

变化侦测和渲染机制

命令式：jQuery，直接通过命令完成功能，会遇到维护性的问题

声明式：声明文档与变量之间的映射关系

Vue采用的是一种混合式的策略，以组件为单位进行响应式的更新，进行virtualDOM的比对。pull是一种暴力的便利比对，进行全局的更新，是粗粒度的，而push是响应式的通知系统哪些数据发生了变化，需要进行更新，是更细粒度的。虽然push更新范围小，会带来性能的提升，但是由于对每一个需要侦测的变量都需要增加观察者，同时响应更新的机制也会带来内存方面的压力。

状态管理

常见的状态管理框架Redux、Mobx， vuex

状态管理的本质：从原事件（source events）映射到状态的迁移，在映射到UI的改变。

（鼠标点击事件→应用状态改变→UI（dom）的改变）

声明式的渲染解决了状态到UI的管理，状态管理解决的是管理事件源映射到状态变化的过程，将映射过程从试图组件中剥离出来，提高可维护性

Redux VS Mobx VS Vuex

范式（paradigm）不同，Redux强调数据不可变，函数式的，reducer是纯函数

Mobx和Vuex是响应式的，数据是可变的，数据可变的副作用是声明式的

本质相同的。

都没有回答如何处理异步。

状态管理如何处理异步

建议使用RXJS来做一层封装处理异步。利用RXJS跳过状态的改变（Redux中的reducer，Vuex中的mutation），利用“流”来管理（需要对RXJS的理解非常高--我就不理解）

状态管理的尴尬

1. 组件内部状态的管理，内部状态和全局状态界限不明显。

2. 全局状态和服务端数据关系

路由

单页应用的路由，本质上是将url映射到组件树结构的过程

React-Router V4

去中心化的路由，利用组件本身去做路由，将路由与组件结合，用组件生命周期做跳转

Web路由与原生路由

浏览模式的区别：Web路由的跳转需要抛弃跳转之前的状态，而原生路由是由新的页面叠加在旧的页面上，后退时将当前页面拿掉

鼓励Vue社区向原生路由的方向发展

主流的 CSS方案

1. 跟 JS 完全解耦，靠预处理器和比如 BEM 这样的规范来保持可维护性，偏传统

2. CSS Modules，依然是 CSS，但是通过编译来避免 CSS 类名的全局冲突

3. 各类 CSS-in-JS 方案，React 社区为代表，比较激进

4. Vue 的单文件组件 CSS，或是 Angular 的组件 CSS（写在装饰器里面），一种比较折中的方案

传统 css 的一些问题

1. 作用域 2. Critical CSS（加载首屏需要的CSS文件） 3. Atomic CSS（将类按最小功能拆分） 4. 分发复用 5. 跨平台复用

CSS-IN-JS未必是未来的方向，很多功能都可以通过对CSS的静态编译实现。

构建工具

磨刀不误砍柴工，构建工具就是在磨刀。

浏览器的限制（代码环境）导致了构建工具的必要性。

1. 任务的自动化

2. 开发体验和效率（新的语言功能，语法糖，hot reload 等等）

3. 部署相关的需求

4. 编译时优化

gulp/grunt：用的较少了，主要价值在于task runner，用于任务自动化，但是现在npm srcipts可以代替其大部分功能，或者用nodeJS手写脚本完成这部分功能，而且这两者在模块化构建方面基本没有特长

关于部署

大公司里怎样开发和部署前端代码？

（https://www.zhihu.com/question/20790576）

由于部署要考虑的问题很复杂（代码的打包合并、本地资源的映射、小尺寸图片的处理等等），导致了webpack配置的复杂，本质上是因为webpack要实现的功能的复杂性

服务端数据通信

GraphQL（http://graphql.cn/）对复杂关联的数据获取比传统的REST抽象要强，对数据量的优化更精确。使用门款较高， 需要后端的支持

是否要将服务端数据放到store中管理

理论上讲，服务端数据对于前端来说是不可变的，前端不能随意更改服务端数据，如果要更改，必须与服务端确认。

所以将服务端数据放到store中是有些多此一举的。

（但是对于大量的数据是不是存在store中，进行增量的修改对性能更有利？）

服务端渲染

Vue SSR指南。（https://ssr.vuejs.org/zh/）

跨平台渲染

将渲染过程与DOM节点解耦。

Web Component

Web Component 和类 React、Angular、Vue 组件化技术谁会成为未来？

（https://www.zhihu.com/question/58731753）

Web Assembly

类似于JS的汇编语言，适合做一些JS中不适于做的大量的计算、3D动画、挖矿等，但是目前无法与DOM接触，对框架影响有限。

react和Vue的场景

场景区别很小，基本可以互换。决定于团队的习惯、技术水平等

前端框架的学习需要到什么程度

理解思想最重要，熟悉源码是为了提升与业务无关的工程化的理解等，对自己写框架、做方案有帮助。

为什么要用服务端渲染

除了SEO的考虑之外，前端渲染的前提是JS全部加载完成，而服务端直出渲染可以减少用户看到内容的时间，对于某些产品，减少用户1s的等待可能会带来更高的转换率，所以是有必要的。

（对于CRM这种内部工具就无所谓了，让他们等着呗。）