一、组件化开发（下）
（一）React渲染机制
1. React的更新机制
2. React的更新流程
React在
props 或 state 发生改变时，会调用React的 render 方法，会创建一棵不同的树。React需要基于这两棵不同的树之间的差别来判断如何有效的更新UI，但是按照目前最先进的比较算法，如果一棵树参考另外一棵树进行完全比较更新，该算法的复杂程度为O(n³)，其中n是树中元素的数量（参考论文文档）
如果在React中使用了该算法，那么展示1000 个元素所需要执行的计算量将在十亿的量级范围，这个开销太过昂贵了，React的更新性能会变得非常低效。
于是，React对这个算法进行了优化，将其优化成了O(n)，优化如下：
- 同层节点之间相互比较，不会垮节点比较；
- 不同类型的节点，产生不同的树结构；
- 开发中，可以通过key来指定哪些节点在不同的渲染下保持稳定；
情况一：对比不同类型的元素
当节点为不同的元素，React会拆卸原有的树，并且建立起新的树：
- 当一个元素从
<a>变成<img>，从<Article>变成<Comment>，或从<Button>变成<div>都会触发一个完整的重建流程；
- 当卸载一棵树时，对应的DOM节点也会被销毁，组件实例将执行
componentWillUnmount()方法；
- 当建立一棵新的树时，对应的DOM节点会被创建以及插入到DOM中，组件实例将执行
componentWillMount()方法，紧接着componentDidMount()方法；
情况二：对比同一类型的元素
当比对两个相同类型的React元素时，React会保留DOM节点，仅比对及更新有改变的属性。如果是同类型的组件元素，组件会保持不变，React会更新该组件的props，并且调用
componentWillReceiveProps() 和 componentWillUpdate() 方法。下一步，调用 render() 方法，diff 算法将在之前的结果以及新的结果中进行递归；E.g.
- 通过比对这两个元素，React知道只需要修改DOM元素上的
className属性；
- 当更新
style属性时，React仅更新有所更变的属性。
通过比对这两个元素，React知道只需要修改DOM元素上的
color 样式，无需修改 fontWeight。情况三：对子节点进行递归
在默认条件下，当递归DOM节点的子元素时，React会同时遍历两个子元素的列表；当产生差异时，生成一个mutation。
- 案例一：假设在最后插入一条数据的情况：前面两个比较是完全相同的，所以不会产生mutation；最后一个比较，产生一个mutation，将其插入到新的DOM树中即可；
- 案例二：如果我们是在中间(前面)插入一条数据：
React会对每一个子元素产生一个mutation，而不是保持
<li>星际穿越</li> 和 <li>盗梦空间</li> 的不变；这种低效的比较方式会带来一定的性能问题；
3. 列表keys的优化
以以下渲染一个列表为例
关于Keys有两种情况：
1️⃣ 在最后位置插入数据，这种情况，有无key意义并不大；
2️⃣ 在前面插入数据，这种做法，在没有key的情况下，所有的item都需要进行修改；
如上述代码，当子元素(即
<li> )拥有key时，React使用key来匹配原有树上的子元素以及最新树上的子元素：在下面这种场景下，key为“星际穿越”和“盗梦空间”的元素仅仅进行位移，不需要进行任何的修改；将key为“大话西游”的元素插入到最前面的位置即可；💡 key的注意事项：
- key应该是唯一的；
- key不要使用随机数（随机数在下一次render时，会重新生成一个数字）；
- 使用index作为key，对性能是没有优化的；
4.1 render函数被调用问题
我们回顾之前一个案例，模拟一个页面。然后我们通过按钮触发
state 的变化并使页面重新渲染，我们通过控制台发现全部组件都重新渲染，并没有根据变化的组件渲染，造成大量的性能浪费。4.2 shouldComponentUpdate 性能优化
shouldComponentUpdate(nextProps, nextState) 方法是手动调用刷新方法，其接受两个参数，第一个是修改后最新的 props 属性，第二个是修改后最新的 state 属性，并且需要boolean类型返回值，返回值为 true，那么就需要调用render方法；反之则不调用。4.3 PureComponent for class
为了提高『4.2』通过手动设置调用
shouldComponentUpdate() 方法，进行依赖刷新的效率，React内部已经为我们实现了一个自动收集依赖并渲染 PureComponent，我们可以尝试以下优化后的代码。🔎从源码的角度去解析
Component 和 PureComponent 的差异：4.4 memo for function
（二）refs
1. 基本使用
在React的开发模式中，通常情况下不需要、也不建议直接操作DOM原生，但是某些特殊的情况，确实需要获取到DOM进行某些操作：
- 管理焦点，文本选择或媒体播放；
- 触发强制动画；
- 集成第三方DOM 库；
目前有三种方式创建refs来获取对应的DOM：
方式一：传入字符串（文档中已废弃）
使用时通过
this.refs. 传入的字符串格式获取对应的元素；- 方式二：传入一个对象
对象是通过
React.createRef() 方式创建出来的，使用时获取到创建的对象其中有一个 current 属性就是对应的元素；- 方式三：传入一个函数
该函数会在DOM被挂载时进行回调，这个函数会传入一个元素对象，我们可以自己保存；使用时，直接拿到之前保存的元素对象即可；
以下是案例代码
2. ref类型
ref 的值根据节点的类型而有所不同：- 当ref 属性用于 HTML元素 时，构造函数中使用
React.createRef()创建的ref接收底层DOM 元素作为其current属性；
- 当
ref属性用于 自定义class组件 时，ref对象接收组件的挂载实例作为其current属性；
- ⚠️ 不能在函数组件上使用
ref属性，因为他们没有实例；（但是某些时候，我们可能想要获取函数式组件中的某个DOM元素，这个时候我们可以通过React.forwardRef，也可以看后面的hooks中如何使用ref；）
下面是一个通过
ref 调用其他组件的方法的案例（三）受控组件与非受控组件（表单）
1. 受控组件基础
在React中，HTML表单的处理方式和普通的DOM元素不太一样：表单元素通常会保存在一些内部的state。比如以下的HTML表单元素：
- 这个处理方式是DOM默认处理HTML表单的行为，在用户点击提交时会提交到某个服务器中，并且刷新页面；
- 在React中，并没有禁止这个行为，它依然是有效的；
- 但是通常情况下会使用JavaScript函数来方便的处理表单提交，同时还可以访问用户填写的表单数据；
- 实现这种效果的标准方式是使用“受控组件”；
在 HTML 中，表单元素（如
<input>、<textarea> 和 <select>）之类的表单元素通常自己维护 state，并根据用户输入进行更新。而在 React 中，可变状态（mutable state）通常保存在组件的
state 属性中，并且只能通过使用 setState() 来更新。我们将两者结合起来，使React的state成为“唯一数据源”，渲染表单的 React 组件还控制着用户输入过程中表单发生的操作，所以被 React 以这种方式控制取值的表单输入元素就叫做“受控组件”。💡由于在表单元素上设置了
value 属性，因此显示的值将始终为 this.state.value，这使得React 的 state 成为唯一数据源。handleUsernameChange 在每次按键时都会执行并更新 React 的 state，因此显示的值将随着用户输入而更新。部分受控组件的属性值和回调函数数据：
Element | Value property | Change callback | New value in the callback |
<input type="text"/> | value="string" | onChange | event.target.value |
<input type="checkbox"/> | checked={boolean} | onChange | event.target.checked |
<input type="radio"/> | checked={boolean} | onChange | event.target.checked |
<textarea /> | value="string" | onChange | event.target.value |
<select /> | value="option value" | onChange | event.target.value |
以下是具体的演示代码
💡需要注意此处是单向数据流，input数据变化会通知state变化，而state变化使UI的input也发生变化
还有另一段演示代码
2. 受控组件多输入-封装案例
如果存在多个输入框，我们需要手动写多个监听方法，效率较低。在这里我们可以使用ES6的一个语法——计算属性名（Computed property names）
3. 非受控组件
React推荐大多数情况下使用受控组件来处理表单数据：一个受控组件中，表单数据是由React 组件来管理的；另一种替代方案是使用非受控组件，这时表单数据将交由DOM节点来处理；
如果要使用非受控组件中的数据，那么我们需要使用
ref 来从DOM节点中获取表单数据，以下是案例代码（四）高阶组件
1. 高阶函数
JavaScript中比较常见的filter、map、reduce都是高阶函数。而高阶函数的维基百科定义：至少满足以下条件之一：
- 接受一个或多个函数作为输入；
- 输出一个函数；
那同理引申到高阶组件，官方对其定义是：高阶组件是参数为组件，返回值为新组件的函数。高阶组件的英文是Higher-Order Components，简称为HOC；
💡 我们可以进行如下的解析：
- 首先， 高阶组件本身不是一个组件，而是一个函数；
- 其次，这个函数的参数是一个组件，返回值也是一个组件；
2. 高阶组件
高阶组件并不是React API的一部分，它是基于React的组合特性而形成的设计模式。高阶组件在一些React第三方库中非常常见，比如redux中的connect、比如react-router中的withRouter。
💡 组件的名称问题
- 在ES6中，类表达式中类名是可以省略的；如果以以下代码14行
class NewComponent extends PureComponent，则在浏览器React工具里面显示的是 PureComponent（即父类的名称）
- 组件的（展示）名称都可以通过
displayName来修改；
以下是高阶组件的简单案例，我们尝试将App包裹起来
3. 高阶组件应用一：props增强（上）
我们可以在不改变原有代码的情况下，添加新的
props；其次假如我们可以通过这种方法抽取出共同的逻辑，方便我们日后的修改，如以下代码：此时不同组件的昵称、等级属性是不同的，但是区域属性是相同的（都是中国）
4. 高阶组件应用二：props增强（下）
利用高阶组件来共享
Context但是我们看到有部分的配置属性也是重复的，可以提取出来，所以我们作出以下优化：
5. 高阶组件应用三：登录鉴权
在开发中，我们可能遇到这样的场景：某些页面是必须用户登录成功才能进行进入，如果用户没有登录成功，那么直接跳转到登录页面。这个时候，我们就可以使用高阶组件来完成鉴权操作：
以下案例假设鉴权的标识符是通过
props 传递，这种思路可以拓展到 E.g. 我们未发送完网络请求就显示loading界面，发送完成显示其他界面6. 高阶组件应用四：生命周期劫持
7. 高阶函数的意义
高阶组件可以针对某些React代码进行更加优雅的处理。早期的React有提供组件之间的一种复用方式是
mixin（目前已经不再建议使用），因为：- Mixin 可能会相互依赖，相互耦合，不利于代码维护
- 不同的Mixin中的方法可能会相互冲突
- Mixin非常多时，组件是可以感知到的，甚至还要为其做相关处理，这样会给代码造成滚雪球式的复杂性
但是HOC也有自己的一些缺陷：
- HOC需要在原组件上进行包裹或者嵌套，如果大量使用HOC，将会产生非常多的嵌套，这让调试变得非常困难；
- HOC可以劫持
props，在不遵守约定的情况下也可能造成冲突；
新的解决方案：Hooks
（五）组件补充
1. forwardRef - ref for function - ref的转发
在前面提到
ref 说过，ref 不能应用于函数式组件：因为函数式组件没有实例，所以不能获取到对应的组件对象。但是，在开发中我们可能想要获取函数式组件中某个元素的DOM，这个时候我们应该如何操作呢？
- 直接传入ref属性；❎
- 通过
forwardRef高阶函数；✅
2. Portals的使用
某些情况下，我们希望渲染的内容独立于父组件，甚至是独立于当前挂载到的DOM元素中（默认都是挂载到id为root的DOM元素上的），E.g. Notification通知提醒框、Modal对话框
Portal 提供了一种将子节点渲染到存在于父组件以外的 DOM 节点的优秀的方案：
- 第一个参数（child）是任何可渲染的 React 子元素，例如一个元素，字符串或fragment；
- 第二个参数（container）是一个DOM 元素；
案例：利用Portals开发Modal组件，它可以将它的子组件渲染到屏幕的中间位置：
开发思路：
- 步骤一：修改index.html添加新的节点
- 步骤二：编写这个节点的样式
- 步骤三：编写组件代码
3. fragment
在之前的开发中，我们总是在一个组件中返回内容时包裹一个div元素。如果我们不希望渲染这样一个div时，我们可以使用Fragment标签
<Fragment>...</Fragment>，Fragment 允许将子列表分组，而无需向 DOM 添加额外节点；React还提供了Fragment的短语法：它看起来像空标签
<> </>，但是，如果我们需要在Fragment中添加 key，那么就不能使用短语法，以下是案例代码：4. StrictMode
StrictMode 是一个用来突出显示应用程序中潜在问题的工具
- 与 Fragment 一样，StrictMode 不会渲染任何可见的UI；
- 它为其后代元素触发额外的检查和警告；
- 严格模式检查仅在开发模式下运行；它们不会影响生产构建；
例如应用程序的任何部分启用严格模式：
上述案例来说，不会对 Header 和 Footer 组件运行严格模式检查。但是，ComponentOne 和 ComponentTwo 以及它们的所有后代元素都将进行检查；
检查的内容：
- 识别不安全的生命周期：
- 使用过时的 ref API（字符串方式）
- 使用废弃的
findDOMNode方法
在之前的React API中，可以通过findDOMNode来获取DOM，不过现在已经不推荐使用了
- 检查意外的副作用
这个组件的constructor会被调用两次，这是严格模式下故意进行的操作，其目的在于查看其中写的一些逻辑代码被调用多次时，是否会产生一些副作用；
在生产环境中，是不会被调用两次的；
- 检测过时的context API
早期的Context是通过static属性声明Context对象属性，通过
getChildContext 返回Context对象等方式来使用Context的；
- 作者:😈Zabanya
- 链接:https://blog.zabanya.space/article/691e1e31-a3a1-475b-a347-6f8e47954637
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处