学习笔记《深入浅出搞定 React》

001 JSX

官方定义：JSX 是 JavaScript 的一种语法扩展，它和模板语言很接近，但是它充分具备 JavaScript 的能力。
JSX 会被 Babel 编译为 React.createElement()，React.createElement() 将返回一个叫做 React ELement 的 JS 对象。
JSX 的本质是React.createElement这个 JavaScript 调用的语法糖，这也就完美地呼应上了 React 官方给出的“JSX 充分具备 JavaScript 的能力”这句话。
createElement 入参数：
- type：用于表示节点的类型，可以是 h1、div，也可以是 React 组件类型或 React fragment 类型。
- config：对象形式，组件所有属性都会以键值对形式存储在 config 中。
- children：对象形式，记录的是标签之间的嵌套内容，也就是“子节点”。
createElement 并没有处理很复杂的逻辑或真实 DOM，就像是开发者和 ReactElement 调用之间的一个转换器、数据处理层。
createElement 做的事情：
- React.createElement。
- 二次处理 key、ref、self、source 四个属性值。
- 遍历 config，筛出可以提进 props的属性。
- 提取子元素，推入 childArray（即 props.children）数组。
- 格式化 type.defaultProps。
- 结合以上数据作为入参，发起 ReactElement 调用。
ReactElement 做的事情：
- 组装，将传入的参数组装到 element 中，并返回。
- 这个 ReactElement 对象实例，本质上是以 JavaScript 对象形式存在的对 DOM 的描述，也就是虚拟DOM。
虚拟 DOM -> 真实 DOM 由 ReactDOM.render 完成。
ReactDOM.render 参数：
- element：需要渲染的 ReactElement。
- container：元素挂载的目标容器，真实DOM。
- [callback]：回调函数，处理渲染结束后的逻辑。

三个问题：

JSX 本质是什么？与 JS 的关系？
- 官方定义：JSX 是 JavaScript 的一种语法扩展，它和模版语言很接近，但是它充分具备 JavaScript 的能力。
- JSX 本质是 React.createElement 这个 JavaScript 调用的语法糖。
- JSX 可以通过 Babel 编译为 JavaScript 代码。
为什么要用 JSX？不用会有什么后果？
- JSX 语法糖允许前端开发者使用我们最为熟悉的类 HTML 标签语法来创建虚拟 DOM，在降低学习成本的同时，也提升了研发效率与研发体验。
背后的功能模块是什么？模块做了哪些事？
- React.createElement -> ReactElement 然后再返回虚拟 DOM 给用户，虚拟 DOM -> 真实 DOM 是由 ReactDOM.render 完成的。

002 React 15、16 生命周期

react 15、16 版本两个生命周期进行探讨、对比、总结。

关键词：组件、虚拟 DOM

React 工作流中虚拟 DOM 作用：
- 组件初始化 -> 调用 render 方法 -> 生成虚拟 DOM -> 调用 ReactDOM.render 方法，实现虚拟 DOM 与真实 DOM 转换。
- 组件更新时 -> 调用 render 方法 -> 生产新的虚拟 DOM -> 借助 diff 定位两次虚拟 DOM 的差异，针对发生变化的真实 DOM 作定向更新。
组件化：
- 封闭：组件间“各自为政”。
- 开放：组件通信，“单向数据流”原则完成通信后，对数据产生影响，进而对渲染结果产生影响。
虚拟DOM、组件化都围绕了 render 生命周期，可以将 render 称之为“灵魂”，则生命周期为“躯干”。
React 15 生命周期：
- 组件初始化（mounting）-> constructor -> componentWillMount -> render() -> componentDidMount。
- 组件更新时（updating） -> componentWillReceiveProps -> shouldComponentUpdate(组件更新：由组件自身触发) -> componentWillUpdate -> render -> componentDidUpdate。
- 组件销毁时（unmounting） -> componentWillUnmount。
- 组件初始化：
  - （挂载）过程组件一生中只能发生一次，组件被初始化，然后会被渲染到真实 DOM 里，完成所谓的“首次渲染”。
  - constructor、componentWillMount、componentDidMount 只会在挂载阶段调用一次。
  - Render 过程并不会操作真实 DOM，它的职能是 将需要渲染的内容返回回来，真实 DOM 的渲染工作是在挂载阶段由 ReactDOM.render 承接的。
  - componentDidMount 在渲染后触发，此时可以操作真实 DOM，例如异步请求数据、数据初始化等。
- 组件更新时：
  - 触发更新有两种形式：
    - 由父组件更新触发的更新
    - 组件自身 setState 触发的更新
  - componentWillReceiveProps(nextProps)，父组件触发的更新和组件自身的更新相比，多出的生命周期方法。nextProps 接收到的新的 props 内容，原来的 props 可以通过 this.props 获取到。componentReceiveProps 并不是由 props 的变化触发的，而是由父组件的更新触发的，如果想要处理更改，请确保当前值与变更值比较。
  - componentWillUpdate 和 componentDidUpdate 在 render 一前一后触发，componentDidUpdate 也通常被当作子组件更新完毕的标志通知父组件。
  - shouldComponentUpdate(nextProps, nextState)
    - React 组件会根据 shouldComponentUpdate 返回的值，来决定是否执行该方法之后的生命周期。默认值是 true。
- 组件销毁时：
  - 产生组件销毁的情况：
    - 组件在父组件中被移除了
    - 组件中设置了 key，父组件在 render 过程中发现 key不一致，则会销毁该组件。

React 16 生命周期的流程大图：https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/
- 组件初始化（mounting）-> constructor -> getDerivedStateFromProps -> render() -> componentDidMount。
- 组件更新时（updating） -> getDerivedStateFromProps -> shouldComponentUpdate(组件更新：由组件自身触发) -> render -> getSnapshotBeforeUpdate -> componentDidUpdate。
- 组件销毁时（unmounting） -> componentWillUnmount。
- 组件初始化：
  - getDerivedStateFromProps 并不是替代 componentWillMount 方法，componentWillMount 是废弃的，getDerivedStateFromProps是新增的
  - getDerivedStateFromProps 三点：
    - 是静态方法，在方法内访问不到 this。
    - 方法接受两个参数 props、 state，分别代表了来自父组件的 props，以及当前组件自身的 state。
    - 需要一个对象格式的返回值。没有返回值会被警告。该返回值用来更新组件的 state。 因此当你确实不存在“使用 props 派生 state ”这个需求的时候，最好是直接省略掉这个生命周期方法的编写，否则一定记得给它 return 一个 null。
  - getDerivedStateFromProps 方法对 state 的更新动作并非“覆盖”式的更新，而是针对某个属性的定向更新。
- 组件更新时：
  - 在 React 16.4 中，任何因素触发的组件更新流程（包括由父组件更新、 this.setState 、forceUpdate 触发的更新流程）都会触发 getDerivedStateFromProps。
  - 而在 v 16.3 版本中，只有父组件的更新会触发该生命周期。
  - getDerivedStateFromProps 生命周期替代 componentWillReceiveProps 的背后，是 React 16 在强制推行“只用 getDerivedStateFromProps 来完成 props 到 state 的映射”这一最佳实践。意在确保生命周期函数的行为更加可控可预测，从根源上帮开发者避免不合理的编程方式，避免生命周期的滥用；同时，也是在为新的 Fiber 架构铺路。
  - getSnapshotBeforeUpdate 的返回值会作为第三个参数给到 componentDidUpdate。它的执行时机是在 render 方法之后，真实 DOM 更新之前。 在这个阶段，可以同时获得更新前的真实 DOM 以及更新前后的 state、props 信息。使用场景：实现一个内容会发生变化的滚动列表，要求根据滚动列表的内容是否发生变化，来决定是否要记录滚动条的当前位置。
  - getSnapshotBeforeUpdate 要想发挥作用，离不开 componentDidUpdate 的配合。 getSnapshotBeforeUpdate 返回值作为 componentDidUpdate(prevProps, prevState, valueFromSnapshot) 第三个参数传入。

003 数据组件间流动

React 的核心特征是“数据驱动视图”，这个特征在业内有一个非常有名的函数式来表达：UI = render(data) 或 UI = f(data)，React 的视图会随着数据的变化而变化
基于 props 的单向数据流。
- 所谓单向数据流，指的就是当前组件的 state 以 props 的形式流动时，只能流向组件树中比自己层级更低的组件。比如在父-子组件这种嵌套关系中，只能由父组件传 props 给子组件，而不能反过来。
- 父 -> 子 props
- 子 -> 父 props 传入函数，函数参数
- 兄弟组件：公用同一个父节点，利用上述两种方式
- 发布 - 订阅：监听事件的位置和触发事件的位置是不受限的
发布- 订阅设计思路
- on()：负责注册事件监听器，指定事件触发时回调。
- emit()：负责触发事件，可以通过传参使其在触发的时候携带参数。
- off()：负责监听器的删除。
- 实现（放在文末）
Context API
- 是官网提供的一种组件树全局通信方式。
- 3个关键要素：React.createContext、Provider、Consumer
- 我们通过调用 React.createContext，可以创建出一组 Provider。Provider 作为数据的提供方，可以将数据下发给自身组件树中任意层级的 Consumer。
Redux
- Redux 是 JavaScript 状态容器，它提供可预测的状态管理。
- Redux 是一个状态容器，状态容器是指：存放公共数据的仓库。假如把一个 React 项目里面的所有组件拉进一个钉钉群，那么 Redux 就充当了这个群里的“群文件”角色，所有的组件都可以把需要在组件树里流动的数据存储在群文件里。当某个数据改变的时候，其他组件都能够通过下载最新的群文件来获取到数据的最新值。
- Redux 三部分组成：store、reducer、action
  - store，就好比群文件，单一的数据源，而且是只读的。
  - action，对变化的描述。
  - Reducer，是一个函数，负责对变化进行分发和处理，将新的数据返回给 store。
- Redux 整个过程中，数据流是严格单向的。如果想要更改数据，只能通过派发 action，aciton 会被 reducer 读取，进而根据 action 内容对数据修改，生成新的 state，新的 state 更新到 store，进而驱使试图层面作出对应改变。
- Redux 通过提供一个统一的状态容器，使得数据能够自由而有序地在任意组件间穿梭，这就是 redux 组件通讯的思路。
- 编码角度：
  - 通过 createStore 创建 store 对象。
  - reducer 的作用是将新的 state 返回给 store。
  - action 的作用是通知 reducer “让改变发生”。
  - 派发 action，通过 dispatch。

发布订阅代码实现

class myEventEmitter {
  constructor() {
    // eventMap 用来存储事件和监听函数之间的关系
    this.eventMap = {};
  }
  // type 这里就代表事件的名称
  on(type, handler) {
    // hanlder 必须是一个函数，如果不是直接报错
    if (!(handler instanceof Function)) {
      throw new Error("哥 你错了 请传一个函数");
    }
    // 判断 type 事件对应的队列是否存在
    if (!this.eventMap[type]) {
      // 若不存在，新建该队列
      this.eventMap[type] = [];
    }
    // 若存在，直接往队列里推入 handler
    this.eventMap[type].push(handler);
  }
  // 别忘了我们前面说过触发时是可以携带数据的，params 就是数据的载体
  emit(type, params) {
    // 假设该事件是有订阅的（对应的事件队列存在）
    if (this.eventMap[type]) {
      // 将事件队列里的 handler 依次执行出队
      this.eventMap[type].forEach((handler, index) => {
        // 注意别忘了读取 params
        handler(params);
      });
    }
  }
  off(type, handler) {
    if (this.eventMap[type]) {
      this.eventMap[type].splice(this.eventMap[type].indexOf(handler) >>> 0, 1);
    }
  }
}

004 React-hooks 设计动机与工作模式

类组件、函数组件
- 类组件：
  - 通过继承 React.Component 得来的 React 组件。
  - 面向对象编程思想。封装、继承。
- 函数组件：
  - 以函数形态存在的 React 组件。
  - 相比类组件，特质包括：轻量、灵活、易于组织和维护、较低的学习成本等。
- 函数组件会捕获 render 内部的状态，这是两类组件最大的不同。
- 类组件和函数组件之间，纵有千差万别，但最不能够被我们忽视掉的，是心智模式层面的差异。
- 函数组件是一个更加匹配其设计理念、也更有利于逻辑拆分与重用的组件表达形式。
React-Hooks
- 本质：是一套能够使函数组件更强大、灵活的“钩子”。我把常用的钩子函数分为有副作用和无副作用以及 useRef ，有副作用包括 useEffect、useMemo、useCallback，无副作用包括 useState、useReducer、useContext
- 为什么需要？
  - 告别难以理解的 Class；
  - 解决业务逻辑难以拆分的问题：我们可以有专门管理订阅的函数组件、专门处理 DOM 的函数组件、专门获取数据的函数组件等。Hooks 能够帮助我们实现业务逻辑的聚合，避免复杂的组件和冗余的代码
  - 使状态逻辑复用变得简单可行；
  - 函数组件从设计思想上来看，更加契合 React 的理念。
- 介绍 useState
- 介绍 useEffect ：允许函数组件执行副作用操作
  - useEffect(callBack)
  - useEffect(() =>{ return ()=>{} })
  - useEffect(callBack, [])
  - useEffect(() =>{ return ()=>{} }, [])
  - useEffect(callBack, [dep])
  - useEffect(() =>{ return ()=>{} }, [dep])
- hooks 局限性
  - Hooks 暂时还不能完全地为函数组件补齐类组件的能力
  - “轻量”几乎是函数组件的基因，这可能会使它不能够很好地消mkdirm化“复杂”
  - Hooks 在使用层面有着严格的规则约束

005 React-hooks 工作机制

一句话总结：根据源码介绍了 hooks 的首次渲染、更新渲染流程和机制。进而得到 hooks 渲染机制是依次遍历， hooks 本质是链表。

hooks 使用原则：
- 只在 react 函数中调用 hook。
- 不要再循环、条件或嵌套函数中使用 hook。
Hooks 首次渲染流程： useState -> 通过 resolveDispatcher 获取 dispatcher -> 调用 dispatcher.useState -> 调用 mountState -> 返回目标数组
Hooks 更新渲染流程： useState -> 通过 resolveDispatcher 获取 dispatcher -> 调用 dispatcher.useState -> 调用 updateState -> 调用 updateReducer -> 返回目标数组
Hooks 的本质是链表。
updateState ：按顺序去遍历之前构建好的链表，取出对应的数据信息进行渲染。
Hooks 的渲染通过“依次遍历”来定位每个 hooks 内容的，如果前后两次读到的链表在顺序上出现差异，那么渲染的结果自然不可控。

006 虚拟 DOM

一句话总结：首先回顾 DOM 操作解决方案发展史，明确了虚拟 DOM 定位和解决的主要问题，之后对虚拟 DOM 流程分析。过程中需要格外注意 diff：是指对比两颗虚拟 DOM 树之间差异的过程。

虚拟 DOM 是什么？
- 本质上是 JS 和 DOM 之间的映射缓存，在形态上表现为一个能够描述 DOM 结构以及其属性信息的JS对象。
- 虚拟DOM 是 JS对象。
- 虚拟 DOM 是对真实 DOM 的描述。
虚拟 DOM 如何工作的？
- 挂载阶段：React 将结合 JSX 的描述，构建出虚拟 DOM 树，然后通过 ReactDOM.render 实现虚拟 DOM 到真实 DOM 的映射（触发渲染流水线）。
- 更新阶段：页面的变化作用于真实 DOM 之前，会先作用于虚拟 DOM，虚拟 DOM 将在 JS 层借助短发先对比出具体有哪些真实 DOM需要被改变，然后将这些改变作用于真实 DOM。
DOM 操作历史
- 原生 JS 直接操作。
- JQuery 时代：封装了 DOM API，同时处理了兼容浏览器问题，提供了链式调用、插件扩展等能力。
- 早起模版引擎方案：模版引擎更倾向于解决繁琐DOM操作问题，并不打算也不能够替换JQuery，和谐共存的，因此是模版引擎方案，而不是模版引擎时期。
  - 模版引擎处理：
    - 读取 HTML 模版并解析他，分离出其中的 JS 信息。
    - 将解析出的内容拼接成字符串，动态生成 JS 代码。
    - 运行动态生成的 JS 代码，吐出 “目标HTML”。
    - 将“目标HTML” 赋值给 innerHTML，触发渲染流水线，完成真实 DOM 渲染。
  - 虽然想法很好，但是在性能上不尽如人意，更新DOM的方式是将一竟然出DOM整体注销在整体渲染，并不存在缓存说法，操作频繁时，可能会导致页面卡死。
- 虚拟DOM
  - 同样是将界面和数据分开
    - 模版引擎：数据+模版 -> 真实DOM -> 挂载到页面
    - 虚拟DOM加持下：数据+“模版” -> 虚拟DOM -> 真实DOM -> 挂载到页面
    - 模版加引号是因为不总是用模版，例如 React 就使用 JSX，JSX 本质不是模版，是 React.createElement 这个 JavaScript 调用的语法糖。
  - 当 DOM 操作较频繁时，会先将前后两次的虚拟DOM树进行对比，定位出具体要更新的部分生成一个补丁集（过程叫 diff），最后将补丁打在需要更新的部分真实DOM上（过程叫 patch），实现精准的“差量更新”。
  - 模板渲染是全量更新，而虚拟 DOM 是差量更新。
React 选用虚拟 DOM，是为了更好的性能嘛？
- 虚拟 DOM 是前端开发们为了追求更好的开发体验和效率创造出的高阶产物。
- 虚拟 DOM 并不一定会带来更好的性能，React 官网也从来没有把虚拟 DOM 作为性能层面的卖点对外输出过。虚拟 DOM 的优越之处在于，它能够提供更爽、更高效的研发模式（也就是函数式的UI编程方式）的同时，仍然保持一个还不错的性能。
- 若两者最终计算出的 DOM 更新内容完全一致，那么虚拟 DOM 大概率不敌模板渲染；但只要两者在最终 DOM 操作量上拉开那么一点点的差距，虚拟 DOM 就将具备战胜模板渲染的底气。虚拟 DOM 的劣势主要在于JS 计算机的耗时，而 DOM 操作的能耗和 JS 计算的能耗根本不在一个量级，极少的 DOM 操作耗费的性能足以支撑大佬的 JS 计算。
虚拟 DOM 的价值
- 解决的关键问题有两个
  - 1. 研发体验/研发效率问题：这一点前面已经反复强调过，DOM 操作模式的每一次革新，背后都是前端对效率和体验的进一步追求。虚拟 DOM 的出现，为数据驱动视图这一思想提供了高度可用的载体，使得前端开发能够基于函数式 UI 的编程方式实现高效的声明式编程。
  - 1. 跨平台的问题：抹平了 web端 native 端的差异，虚拟DOM描述的可以是真实DOM，也可以是 IOS界面，安卓界面，小程序等，同一套虚拟DOM，可以对接不同平台渲染逻辑，从而实现“一次编码，多端运行”。
除了差量更新，批量更新也是虚拟 DOM 在性能方面做的一个努力。如极短时间内多次操作同一个DOM，前几次更新的动作意义不大，这是需要 batch 帮忙，batch 的作用是缓冲每次生成的补丁集，会把收集到的多个补丁集暂存到dailies，将最终的结果交给渲染函数，实现集中化 DOM 批量处理。

最后，虚拟 DOM 的存在，不能片面的说他解决了真实DOM更新试图带来的性能问题，是提升试图渲染性能存在的。虚拟DOM 是让diff 算法提供了可能。并且为编译多平台代码提供了可能，我们可以在虚拟dom转换真是节点做文章，除此之外，还提升了开发体验和开发效率，使得UI=fn(state) 数据驱动视图的函数式、声明式编程成为可能。

007 栈调和过程

一句话介绍：首先介绍了调和和 diff 区别，其次说明了 react 15 diff 整体逻辑，把握到“树递归”这一层即可。

React 15 的栈调和过程与 Diff 算法
- 调和（协调）定义：通过如 ReactDOM 等类库使虚拟DOM 与“真实的”DOM同步，这一过程叫作协调（调和）。
- 说人话解释：调和是指，将虚拟 DOM 映射到真实DOM的过程。严格来说，调和过程不能和diff划等号。调和是“使一致”的过程，而 diff 是“找不同”的过程，只是“使一致”过着的一个环节。
- React 源码分为：core、renderer、reconciler三部分。reconciler 所做的工作是一系列包括：组件挂载、卸载、更新等过程，更新过程就涉及对 diff 算法调用。所以说调和 !== diff。但是讨论调和其实就是在讨论diff，Diff 确实是调和过程中最具代表性的一环。根据 diff 实现形式不同，分为：以 React 15 为代表的“栈调和”、以 React 16 以来的“Fiber 调和”。
Diff 算法就是找两棵树的不同，差量更新，并将时间复杂度从 n三次方将为 n。实现可以分为以下三点：
- 分层处理：分层处理是关键点，同层比较，跨层操作会进行销毁 + 重建。
- 类型一致的节点才有继续 diff 的必要性：类型不同直接原地替换掉旧节点。
- Key 属性：key作为唯一标识，可以减少同一层级节点不必要的比较。

008 setState 介绍

setState 被 React 的 isBatchingUpdates 变量管控是直接执行还是批量处理，isBatchingUpdates 被 batchingUpdates 事件管控，batchingUpdates 事件触发在 React 可控范围内的每一次事件。batchingUpdates 结束后，会由“事务”机制执行 close，将isBatchingUpdates 更改为 false，因此在 setTimeout、setInterval 等事件中执行为同步，因为已经在真正执行内容前已经被设置为 false。还有在 React 无法控制，如原生事件内也为同步。

异步动机和原理 - 批量更新
- 异步：避免频繁的re-render
- 批处理：每来一个 setState，就把它塞进一个队列里“攒起来”。等时机成熟，再把“攒起来”的 state 结果做合并，最后只针对最新的 state 值走一次更新流程。这个过程，叫作“批量更新”
并不是 setTimeout 改变了 setState，而是 setTimeout 帮助 setState “逃脱”了 React 对它的管控。只要是在 React 管控下的 setState，一定是异步的。

其中比较值得注意的是 isBatchingUpdates 这个属性，直接决定了更新流程，batchingStrategy 或许正是 react 内部管理批量更新对象。
锁和事务
batchingUpdates 方法其他触发时机：
- 首次渲染组件执行。
- 为组件绑定事件，事件触发时触执行。
isBatchingUpdates 这个变量，在 React 的生命周期函数以及合成事件执行前，已经被 React 悄悄修改为了 true，这时我们所做的 setState 操作自然不会立即生效。当函数执行完毕后，事务的 close 方法会再把 isBatchingUpdates 改为 false，关闭批处理，所以是异步执行的。但是 setTimeout 的逻辑是异步的，setTimeout 代码真正执行时，isBatchingUpdates 已经设置为 false 了，所以是同步执行。
setState 并不是单纯同步/异步的，它的表现会因调用场景的不同而不同：在 React 钩子函数及合成事件中，它表现为异步；而在 setTimeout、setInterval 等函数中，包括在 DOM 原生事件中，它都表现为同步。这种差异，本质上是由 React 事务机制和批量更新机制的工作方式来决定的。

fanxinjie / blog

学习笔记《深入浅出搞定 React》 #6

001 JSX

002 React 15、16 生命周期

003 数据组件间流动

004 React-hooks 设计动机与工作模式

005 React-hooks 工作机制

006 虚拟 DOM

007 栈调和过程

008 setState 介绍