大鹿
Jiann
Do not go gentle into that good night. 🏕️

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

live链接

前言:不同框架的定位与适用场景

框架、语言没有好坏,不谈场景都是耍流氓,前端是产品差异很大的平台,不同场景的需求有很大的差别,其次,开发者群体是多样化的,处于学习背景,习惯,思维模式差异,与其争论哪个好坏,不如选择适合你的。
如何选择框架:透过框架表层,去理解框架解决的问题

组件的理解和分类

页面app可以由组件树组成

  1. 展示型组件
  2. 接入行组件container,会与数据层进行打交道,通常由一些展示型组件构成
  3. 交互型组件,比如表单组件,大部分组件库都是这类,会有比较复杂的交互逻辑,强调复用
  4. 功能型组件,如react-router,本身不展示,只是对逻辑的封装

jsx:本质是js,优点:灵活性。非常方便的编写功能型组件
模板:纯展示性的写起来更加舒服,强制性的让逻辑尽可以少的放在视图里,更加容易控制样式
colocation:组件的样式,doc等应该划分到一起,同一文件或者同一文件夹。如css-in-js

声明式编程和命令式编程

  1. Imperative 命令式:jq直接操作dom
  2. Declarative 声明式:直接描述数据与dom之间的关系,不需要手动的去做这些操作

view = render(state),输入是state,输出是dom,描述了关系之后,不需要再顾虑输入到输出中间发生了声明

变化侦测机制

Reactivity in Frontend JavaScript Frameworks

两种形式:

  1. pull:reactd的setState和vue的脏检查都属于pull。需要一个信号告诉系统数据变了,系统进行暴力比对哪里变更了。在大型系统需要人为的去减小需要做的暴力比对,如shouldUpdate
  2. push:vue响应式,rxjs中Observable。 以更小的粒度去检测更新。当粒度够细,watch和overable内存的开销会比较大。用侦测成本换取一定程度的性能优化

常见状态管理

本质:事件源->映射到状态的迁移->映射到ui的变更。 状态管理处理的是事件源映射到数据状态变化的过程,将这些逻辑从视图组件中剥离出来

  1. redux:Paradigms范式,强调数据不可变性,函数式。通过 state + action 返回新的 state
  2. mobx + vuex:在可变数据上做了副作用的声明,自动化处理观察数据的变化
  3. rxjs

面临的一些问题

  • 组件的全局状态和局部状态如何区分,只被某个组件使用的状态放到全局状态是多此一举,但是在全局和局部状态之间,没有明确的区分
  • 全局状态和服务端数据处理

路由

  • 传统路由:ember的路由,侵入性强,每个路由有对应的数据,显示层。
  • react-router,vue-router:本质上把url映射到一个组件树的过程。

需要解决的问题

  • hash和history模式的兼容
  • 重定向
  • 叠名
  • 懒加载
  • 跳转时候的钩子,涉及异步,取消跳转

去中心化的路由(react-router)

把路由表分散到各个组件,灵活性非常好。缺点:对跳转的管理会弱一点。集中式路由表对于理解整个项目是有帮助的。

页面路由和原生应用

  • 页面路由:页面是完全替换
  • 原生应用:页面是一层一层往上层叠

CSS 管理方案

  1. JS 完全解耦,靠预处理器和比如 BEM 这样的规范来保持可维护性,偏传统
  2. CSS Modules,依然是 CSS,但是通过编译来避免 CSS 类名的全局冲突
  3. 各类 CSS-in-JS 方案,React 社区为代表,比较激进
  4. Vue 的单文件组件 CSS,或是 Angular 的组件 CSS(写在装饰器里面),一种比较折中的方案

React: CSS in JS
A Unified Styling Language

传统 css 的一些问题:

  1. 作用域
  2. 服务端Critical CSS,首屏单独加载对应的样式,服务器端需要判定当前页需要哪些样式
  3. 体积优化Atomic CSS,
  4. 分发复用
  5. 跨平台复用

构建工具链

主要解决的问题

  1. 任务的自动化
  2. 开发体验和效率(新的语言功能,语法糖,hot reload 等等)
  3. 部署相关的需求
  4. 编译时优化

grunt,gulp:task runing,npm script基本都能实现
webpack:以模块的形式去管理

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

服务端数据通信

  1. 通过restfulApi获取数据
  2. 关连型数据复杂的情况下:GraphQL & Relay,
  3. 实时数据处理:Firebase,rethinkDB,rxjs

服务端数据是否应该放到前端的状态管理:前端不应该去变更数据,只能与服务器进行交互,存储于是否多此一举。 Netty,可以用Relay等声明式的在组件里面声明需要声明数据封装起来暴露给前端

跨平台渲染

本质是:实现框架的渲染机制和dom解耦,把框架更新时的节点操作封装起来去对接各个平台渲染引擎的节点操作
各个框架对比的点

  • 框架开发时的体验
  • 底层渲染引擎在运行时的性能和稳定性

新规范

Web Component 和类 React、Angular、Vue 组件化技术谁会成为未来?
WebAssembly:适合用于需要大量计算的场景,,如视频、React的dom diff、3D 网页游戏等 WebAssembly 现状与实战

总结

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

答疑

对于前端框架的学习需要到什么程度才算比较好?熟悉源码?理解思想?还是其他什么

熟悉源码:涉及非常复杂的业务。更多的是提升自己的工程化,模式,代码细节,了解大型项目如何组合起来。对自己写库,写方案有帮助

现在HTTP/2越来越普及,前端构建工具在针对HTTP/2上怎么去找一个平衡点呢?

需要实际中去测试分析