推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 挨踢屌丝 > 尤雨溪-不吹不黑聊聊前端框架

尤雨溪-不吹不黑聊聊前端框架

挨踢屌丝 2018-10-26

本文是自己在知乎购买的live,将尤大的语音整理成文本,算是发福利吧。如果这样不被允许,只要有人通知我,我一定删除。


如何根据不同的场景需求去选择工具?

基于经验和工具本身的理解

组件:

1 主流框架都已经将组件作为一个抽象单元(*.vue文件)

2 最早的前端以页面为单位,应用的出现使得模块切分出现需求

3 React的贡献就是揭示了组件可以是一个函数

4 一个组件是一个函数,一个组件可以调用其他函数,组件可以调用组件,在这个过程中vdom在被操作,从而更新的时候页面发生了变化

5 vue组件中的script是受限作用域的,包括模板中的事件绑定的执行函数也是受限的,而不是全局的;全局的函数你根本不知道这个函数会调用哪里的变量,这会造成维护性的问题

组件分为四类

1 纯展示型的组件

2 接入型组件:会跟数据层的service打交道,container

3 交互型组件:对表单组件的封装和加强:element,强调复用

4 功能型组件:路由<router-view>,作为一种扩展抽象机制存在,jsx实现

jsx:本质上就是JavaScript

变化侦测和渲染机制:

声明式:

1 直接描述数据跟dom结构之间的映射关系,这样就不用手动的去做更新操作 ;

2 view = render(state);

3 view的目标也是编译成渲染函数的;

4 输入state,输出dom

5 输入变了输出就变了,这样就不用顾虑输入到输出之间发生了什么事情。

6 底层实现可以是virtual dom,也可以是细粒度的绑定,比如vue1

7 不同的底层实现在不同的场景下更新的效率不同,本质相同

8 Vue服务端渲染指南:https://ssr.vuejs.org/

9 跨平台渲染:跨平台渲染的本质是在设计框架的时候,让框架的渲染机制跟dom解耦;有多种实现方式,并不一定要是virtual dom;每个平台都有一个渲染引擎并暴露节点操作的API,只要将框架的运行时对接到渲染引擎的API即可达到跨平台渲染;三大主流框架都做到了跟具体的底层渲染解耦,但是比较的时候要考虑开发体验、性能、稳定。要分开比较。

变化侦测:

1 尤雨溪:巴黎演讲的PPT https://docs.google.com/presentation/d/1_BlJxudppfKmAtfbNIcqNwzrC5vLrR_h1e09apcpdNY/edit?usp=sharing

百度云:https://pan.baidu.com/s/1KeM3iV4O7DgBacZ6BST0iQ

2 变化侦测主要包括:push和pull两种

3 pull :

1)Angular1,2 脏检查;

2)系统需要给出一个信号说数据可能变了,这个时候系统进行一次比较暴力的比对;

3)React里面是vdom的diff;在Angular里面是脏检查的整个流程;之所以这么做是因为我们根本就不知道哪些数据变了;

4)能够这么做是因为JavaScript目前足够快;

5)最粗粒度的更新

6)在大型应用里,我们需要帮助这个系统来减少一些无用功,在组件树中跳过一部分来避免暴力比对

4 push:

1)Vue的响应式的数据;

2)数据变动机制使得数据变了以后我们立刻就会知道数据变了;

3)一定程度上知道是哪些数据变了,从而可以进行更细粒度的更新;

4)代价就是每一个绑定都有一个watcher,从而带来相应内存的开销,依赖追踪的开销;

5)Vue2里面选择了一个中等粒度的开销:组件级别是push(当数据变了的时候我们可以知道哪个组件变了);每一个组件内部是一个响应式的watcher,使用vdom比对;

状态管理:

1 最早来自于Flux。Flux 初期混乱,后来合流到Redux(2015年),再后来出现Mobx(几乎和Vue的Vuex一样)

2 Vuex一定程度受Redux影响

3 状态管理的本质:从源事件(source event)映射到状态的改变,再映射到UI的变化。通俗的说就是有人按了个按钮,触发了鼠标点击事件,映射到了一次应用状态的改变,应用状态的改变最后成为UI dom的改变。

4 状态管理的本质2:将事件源到状态改变的映射过程从视图组件中剥离出来,如何组织这部分代码来提高可维护性。

5 Vue可以当做redux用,也可以当做mobx用很难说谁比谁好,更多的是相似,也都有相同的问题。这些方案其实都没有回答如何处理异步。各种方案都有,写出来的代码也几乎完全不同。大多都是杀鸡用牛刀。典型的rest API是不存在比较复杂的异步的(比如服务端推送、实时)。

6 状态管理的问题:组件的局部状态和全局状态如何区分;有些状态需要被多个组件公用,所以使全局状态;有些状态只被一个组件使用;全局状态和局部状态并没有一个明显的区分

路由:

1 只有大型的单页应用才会遇到路由的问题。

2 最早是ember使用路由,很重的一个框架,而且是侵入式的。写应用要先写路由。

3 Vue和React出现之后,发现路由和组件可以解耦,而且可以更灵活

4 路由本质上是把一个URL映射到组件树结构的一个过程

5 重定向、别名、晚加载、跳转(需要提供各种钩子)

6 去中心化的路由有利也有弊,不利于跳转,不利于统一管理,路由和组件耦合

7 push做的跳转回丢弃当前页面的状态

CSS:

主流的 CSS 方案

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

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

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

- Vue 的单文件组件 CSS,或是 Angular 的组件 CSS(写在装饰器里面),一种比较折中的方案

传统 css 的一些问题:

1. 作用域:Vue中css scoped,其他框架也都有解决方案

2. Critical CSS:首屏风格。服务端渲染如果没有在首页发送给用户之前就加载所有CSS,会导致用户先看到一个没有CSS的首页,看起来很奇怪;如果在首屏发送给用户之前加载所有CSS又会导致性能问题;CSS in JS做这个是比较简单的,可以灵活控制加载那些CSS

3. Atomic CSS

4. 分发复用:由于CSS in JavaScript是JavaScript,所以可以发包引用import

5. 跨平台复用

6 整体上对CSS in JavaScript持有保留态度,因为没有什么是必须要这么做的,其他方案更简单

构建工具:

1 之所以会出现构建工具,是因为web前端平台能力变的越来越强;需求越来越复杂,要求越来越高;

2 构建工具解决的其实是几方面的问题:

- 任务的自动化

- 开发体验和效率(新的语言功能,语法糖,hot reload 等等)

- 部署相关的需求

- 编译时优化

3 前端代码最终要跑在浏览器里面,一些新的语法特性都必须依赖构建来做一个翻译;我们对最终代码跑的环境没有控制权,所以我们只能在构建这一步去下功夫;这种转关规则也都有现成的各种开源工具;

4 极大的提高了开发效率

5 webpack复杂是因为它要解决的问题本身就复杂,比如请求合并,静态资源缓存等等设计到访问效率的场景:https://www.zhihu.com/question/20790576

但是webpack会让你在配置上花一次时间,后面可以反复受益。

6 编译优化是这方面主要的解决方案

服务端数据通信:

1 长久以来,这部分都是围绕restful api ,对于传统的CRUD的应用来说,这种是比较简单的情况。

2 复杂的情况: 数据之间有很大的关联性;实时推送、同步需求。传统的基于REST API的抽象遇到这种场景会比较痛苦。

3 实时的方案有metia、单纯做数据层的有filebase、实时数据库有rthinkdb、jxjs最适合处理事件流、数据关联性很强的场景有基于图的API解决方案


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《尤雨溪-不吹不黑聊聊前端框架》的版权归原作者「挨踢屌丝」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注挨踢屌丝微信公众号

挨踢屌丝微信公众号:gh_e20c4ce3a7f3

挨踢屌丝

手机扫描上方二维码即可关注挨踢屌丝微信公众号

挨踢屌丝最新文章

精品公众号随机推荐