vue 或者react 优化整体优化

  1. 虚构dom

为什么虚构 dom 会进步性能?(必考)

虚构 dom 相当于在 js 和实在 dom 两头加了一个缓存，利用 dom diff 算法防止了没有必要的 dom 操作，从而进步性能。

用 JavaScript 对象构造示意 DOM 树的构造；而后用这个树构建一个真正的 DOM 树，插到文档当中当状态变更的时候，从新结构一棵新的对象树。而后用新的树和旧的树进行比拟，记录两棵树差别把 2 所记录的差别利用到步骤 1 所构建的真正的 DOM 树上，视图就更新了。

React如何获取组件对应的DOM元素？

能够用ref来获取某个子节点的实例，而后通过以后class组件实例的一些特定属性来间接获取子节点实例。ref有三种实现办法:

  • 字符串格局：字符串格局，这是React16版本之前用得最多的，例如：<p ref="info">span</p>
  • 函数格局：ref对应一个办法，该办法有一个参数，也就是对应的节点实例，例如：<p ref={ele => this.info = ele}></p>
  • createRef办法：React 16提供的一个API，应用React.createRef()来实现 　　　　　　

React 废除了哪些生命周期？为什么？

被废除的三个函数都是在render之前，因为fber的呈现，很可能因为高优先级工作的呈现而打断现有工作导致它们会被执行屡次。另外的一个起因则是，React想束缚使用者，好的框架可能让人不得已写出容易保护和扩大的代码，这一点又是从何谈起，能够从新减少以及行将废除的生命周期剖析动手

1) componentWillMount

首先这个函数的性能齐全能够应用componentDidMount和 constructor来代替，异步获取的数据的状况下面曾经阐明了，而如果抛去异步获取数据，其余的即是初始化而已，这些性能都能够在constructor中执行，除此之外，如果在 willMount 中订阅事件，但在服务端这并不会执行 willUnMount事件，也就是说服务端会导致内存透露所以componentWilIMount齐全能够不应用，但使用者有时候不免因为各 种各样的状况在 componentWilMount中做一些操作，那么React为了束缚开发者，罗唆就抛掉了这个API

2) componentWillReceiveProps

在老版本的 React 中，如果组件本身的某个 state 跟其 props 密切相关的话，始终都没有一种很优雅的解决形式去更新 state，而是须要在 componentWilReceiveProps 中判断前后两个 props 是否雷同，如果不同再将新的 props更新到相应的 state 下来。这样做一来会毁坏 state 数据的繁多数据源，导致组件状态变得不可预测，另一方面也会减少组件的重绘次数。相似的业务需要也有很多，如一个能够横向滑动的列表，以后高亮的 Tab 显然隶属于列表本身的时，依据传入的某个值，间接定位到某个 Tab。为了解决这些问题，React引入了第一个新的生命周期：getDerivedStateFromProps。它有以下的长处∶

  • getDSFP是静态方法，在这里不能应用this，也就是一个纯函数，开发者不能写出副作用的代码
  • 开发者只能通过prevState而不是prevProps来做比照，保障了state和props之间的简略关系以及不须要解决第一次渲染时prevProps为空的状况
  • 基于第一点，将状态变动（setState）和低廉操作（tabChange）辨别开，更加便于 render 和 commit 阶段操作或者说优化。

3) componentWillUpdate

与 componentWillReceiveProps 相似，许多开发者也会在 componentWillUpdate 中依据 props 的变动去触发一些回调 。 但不论是 componentWilReceiveProps 还 是 componentWilUpdate，都有可能在一次更新中被调用屡次，也就是说写在这里的回调函数也有可能会被调用屡次，这显然是不可取的。与 componentDidMount 类 似， componentDidUpdate 也不存在这样的问题，一次更新中 componentDidUpdate 只会被调用一次，所以将原先写在 componentWillUpdate 中 的 回 调 迁 移 至 componentDidUpdate 就能够解决这个问题。

另外一种状况则是须要获取DOM元素状态，然而因为在fber中，render可打断，可能在wilMount中获取到的元素状态很可能与理论须要的不同，这个通常能够应用第二个新增的生命函数的解决 getSnapshotBeforeUpdate(prevProps, prevState)

4) getSnapshotBeforeUpdate(prevProps, prevState)

返回的值作为componentDidUpdate的第三个参数。与willMount不同的是，getSnapshotBeforeUpdate会在最终确定的render执行之前执行，也就是能保障其获取到的元素状态与didUpdate中获取到的元素状态雷同。官网参考代码：

class ScrollingList extends React.Component {  constructor(props) {    super(props);    this.listRef = React.createRef();  }  getSnapshotBeforeUpdate(prevProps, prevState) {    // 咱们是否在 list 中增加新的 items ？    // 捕捉滚动地位以便咱们稍后调整滚动地位。    if (prevProps.list.length < this.props.list.length) {      const list = this.listRef.current;      return list.scrollHeight - list.scrollTop;    }    return null;  }  componentDidUpdate(prevProps, prevState, snapshot) {    // 如果咱们 snapshot 有值，阐明咱们刚刚增加了新的 items，    // 调整滚动地位使得这些新 items 不会将旧的 items 推出视图。    //（这里的 snapshot 是 getSnapshotBeforeUpdate 的返回值）    if (snapshot !== null) {      const list = this.listRef.current;      list.scrollTop = list.scrollHeight - snapshot;    }  }  render() {    return (      <div ref={this.listRef}>{/* ...contents... */}</div>    );  }}

如何应用4.0版本的 React Router？

React Router 4.0版本中对 hashHistory做了迁徙，执行包装置命令 npm install react-router-dom后，依照如下代码进行应用即可。

import { HashRouter, Route, Redirect, Switch } from " react-router-dom";class App extends Component {  render() {    return (      <div>        <Switch>          <Route path="/list" componen t={List}></Route>          <Route path="/detail/：id" component={Detail}>            {" "}          </Route>          <Redirect from="/ " to="/list">            {" "}          </Redirect>        </Switch>      </div>    );  }}const routes = (  <HashRouter>    <App> </App>  </HashRouter>);render(routes, ickt);

React申明组件有哪几种办法，有什么不同？

React 申明组件的三种形式：

  • 函数式定义的无状态组件
  • ES5原生形式React.createClass定义的组件
  • ES6模式的extends React.Component定义的组件

（1）无状态函数式组件 它是为了创立纯展现组件，这种组件只负责依据传入的props来展现，不波及到state状态的操作
组件不会被实例化，整体渲染性能失去晋升，不能拜访this对象，不能拜访生命周期的办法

（2）ES5 原生形式 React.createClass // RFC React.createClass会自绑定函数办法，导致不必要的性能开销，减少代码过期的可能性。

（3）E6继承模式 React.Component // RCC 目前极为举荐的创立有状态组件的形式，最终会取代React.createClass模式；绝对于 React.createClass能够更好实现代码复用。

无状态组件绝对于于后者的区别： 与无状态组件相比，React.createClass和React.Component都是创立有状态的组件，这些组件是要被实例化的，并且能够拜访组件的生命周期办法。

React.createClass与React.Component区别：

① 函数this自绑定

  • React.createClass创立的组件，其每一个成员函数的this都有React主动绑定，函数中的this会被正确设置。
  • React.Component创立的组件，其成员函数不会主动绑定this，须要开发者手动绑定，否则this不能获取以后组件实例对象。

② 组件属性类型propTypes及其默认props属性defaultProps配置不同

  • React.createClass在创立组件时，无关组件props的属性类型及组件默认的属性会作为组件实例的属性来配置，其中defaultProps是应用getDefaultProps的办法来获取默认组件属性的
  • React.Component在创立组件时配置这两个对应信息时，他们是作为组件类的属性，不是组件实例的属性，也就是所谓的类的动态属性来配置的。

③ 组件初始状态state的配置不同

  • React.createClass创立的组件，其状态state是通过getInitialState办法来配置组件相干的状态；
  • React.Component创立的组件，其状态state是在constructor中像初始化组件属性一样申明的。

React中refs的作用是什么？有哪些利用场景？

Refs 提供了一种形式，用于拜访在 render 办法中创立的 React 元素或 DOM 节点。Refs 应该审慎应用，如下场景应用 Refs 比拟适宜：

  • 解决焦点、文本抉择或者媒体的管制
  • 触发必要的动画
  • 集成第三方 DOM 库

Refs 是应用 React.createRef() 办法创立的，他通过 ref 属性附加到 React 元素上。要在整个组件中应用 Refs，须要将 ref 在构造函数中调配给其实例属性：

class MyComponent extends React.Component {  constructor(props) {    super(props)    this.myRef = React.createRef()  }  render() {    return <div ref={this.myRef} />  }}

因为函数组件没有实例，因而不能在函数组件上间接应用 ref：

function MyFunctionalComponent() {  return <input />;}class Parent extends React.Component {  constructor(props) {    super(props);    this.textInput = React.createRef();  }  render() {    // 这将不会工作！    return (      <MyFunctionalComponent ref={this.textInput} />    );  }}

但能够通过闭合的帮忙在函数组件外部进行应用 Refs：

function CustomTextInput(props) {  // 这里必须申明 textInput，这样 ref 回调才能够援用它  let textInput = null;  function handleClick() {    textInput.focus();  }  return (    <div>      <input        type="text"        ref={(input) => { textInput = input; }} />      <input        type="button"        value="Focus the text input"        onClick={handleClick}      />    </div>  );  }

留神：

  • 不应该适度的应用 Refs

  • ref 的返回值取决于节点的类型：

    • 当 ref 属性被用于一个一般的 HTML 元素时，React.createRef() 将接管底层 DOM 元素作为他的 current 属性以创立 ref。
    • 当 ref 属性被用于一个自定义的类组件时，ref 对象将接管该组件已挂载的实例作为他的 current。
  • 当在父组件中须要拜访子组件中的 ref 时可应用传递 Refs 或回调 Refs。

参考 前端进阶面试题具体解答

React 组件中怎么做事件代理？它的原理是什么？

React基于Virtual DOM实现了一个SyntheticEvent层（合成事件层），定义的事件处理器会接管到一个合成事件对象的实例，它合乎W3C规范，且与原生的浏览器事件领有同样的接口，反对冒泡机制，所有的事件都主动绑定在最外层上。

在React底层，次要对合成事件做了两件事：

  • 事件委派： React会把所有的事件绑定到构造的最外层，应用对立的事件监听器，这个事件监听器上维持了一个映射来保留所有组件外部事件监听和处理函数。
  • 主动绑定： React组件中，每个办法的上下文都会指向该组件的实例，即主动绑定this为以后组件。

state 和 props 触发更新的生命周期别离有什么区别？

state 更新流程： 这个过程当中波及的函数：

  1. shouldComponentUpdate: 当组件的 state 或 props 产生扭转时，都会首先触发这个生命周期函数。它会接管两个参数：nextProps, nextState——它们别离代表传入的新 props 和新的 state 值。拿到这两个值之后，咱们就能够通过一些比照逻辑来决定是否有 re-render（重渲染）的必要了。如果该函数的返回值为 false，则生命周期终止，反之持续；
留神：此办法仅作为性能优化的形式而存在。不要希图依附此办法来“阻止”渲染，因为这可能会产生 bug。应该思考应用内置的 PureComponent 组件，而不是手动编写 shouldComponentUpdate()
  1. componentWillUpdate：当组件的 state 或 props 产生扭转时，会在渲染之前调用 componentWillUpdate。componentWillUpdate 是 React16 废除的三个生命周期之一。过来，咱们可能心愿能在这个阶段去收集一些必要的信息（比方更新前的 DOM 信息等等），当初咱们齐全能够在 React16 的 getSnapshotBeforeUpdate 中去做这些事；
  2. componentDidUpdate：componentDidUpdate() 会在UI更新后会被立刻调用。它接管 prevProps（上一次的 props 值）作为入参，也就是说在此处咱们依然能够进行 props 值比照（再次阐明 componentWillUpdate 的确鸡肋哈）。

props 更新流程： 绝对于 state 更新，props 更新后惟一的区别是减少了对 componentWillReceiveProps 的调用。对于 componentWillReceiveProps，须要晓得这些事件：

  • componentWillReceiveProps：它在Component承受到新的 props 时被触发。componentWillReceiveProps 会接管一个名为 nextProps 的参数（对应新的 props 值）。该生命周期是 React16 废除掉的三个生命周期之一。在它被废除前，能够用它来比拟 this.props 和 nextProps 来从新setState。在 React16 中，用一个相似的新生命周期 getDerivedStateFromProps 来代替它。

React 事件机制

<div onClick={this.handleClick.bind(this)}>点我</div>

React并不是将click事件绑定到了div的实在DOM上，而是在document处监听了所有的事件，当事件产生并且冒泡到document处的时候，React将事件内容封装并交由真正的处理函数运行。这样的形式不仅仅缩小了内存的耗费，还能在组件挂在销毁时对立订阅和移除事件。

除此之外，冒泡到document上的事件也不是原生的浏览器事件，而是由react本人实现的合成事件（SyntheticEvent）。因而如果不想要是事件冒泡的话应该调用event.preventDefault()办法，而不是调用event.stopProppagation()办法。 JSX 上写的事件并没有绑定在对应的实在 DOM 上，而是通过事件代理的形式，将所有的事件都对立绑定在了 document 上。这样的形式不仅缩小了内存耗费，还能在组件挂载销毁时对立订阅和移除事件。

另外冒泡到 document 上的事件也不是原生浏览器事件，而是 React 本人实现的合成事件（SyntheticEvent）。因而咱们如果不想要事件冒泡的话，调用 event.stopPropagation 是有效的，而应该调用 event.preventDefault。

实现合成事件的目标如下：

  • 合成事件首先抹平了浏览器之间的兼容问题，另外这是一个跨浏览器原生事件包装器，赋予了跨浏览器开发的能力；
  • 对于原生浏览器事件来说，浏览器会给监听器创立一个事件对象。如果你有很多的事件监听，那么就须要调配很多的事件对象，造成高额的内存调配问题。然而对于合成事件来说，有一个事件池专门来治理它们的创立和销毁，当事件须要被应用时，就会从池子中复用对象，事件回调完结后，就会销毁事件对象上的属性，从而便于下次复用事件对象。

对React-Fiber的了解，它解决了什么问题？

React V15 在渲染时，会递归比对 VirtualDOM 树，找出须要变动的节点，而后同步更新它们， 零打碎敲。这个过程期间， React 会占据浏览器资源，这会导致用户触发的事件得不到响应，并且会导致掉帧，导致用户感觉到卡顿。

为了给用户制作一种利用很快的“假象”，不能让一个工作长期霸占着资源。 能够将浏览器的渲染、布局、绘制、资源加载(例如 HTML 解析)、事件响应、脚本执行视作操作系统的“过程”，须要通过某些调度策略正当地调配 CPU 资源，从而进步浏览器的用户响应速率, 同时兼顾工作执行效率。

所以 React 通过Fiber 架构，让这个执行过程变成可被中断。“适时”地让出 CPU 执行权，除了能够让浏览器及时地响应用户的交互，还有其余益处:

  • 分批延时对DOM进行操作，防止一次性操作大量 DOM 节点，能够失去更好的用户体验；
  • 给浏览器一点喘息的机会，它会对代码进行编译优化（JIT）及进行热代码优化，或者对 reflow 进行修改。

核心思想: Fiber 也称协程或者纤程。它和线程并不一样，协程自身是没有并发或者并行能力的（须要配合线程），它只是一种管制流程的让出机制。让出 CPU 的执行权，让 CPU 能在这段时间执行其余的操作。渲染的过程能够被中断，能够将控制权交回浏览器，让位给高优先级的工作，浏览器闲暇后再复原渲染。

React中有应用过getDefaultProps吗？它有什么作用？

通过实现组件的getDefaultProps，对属性设置默认值（ES5的写法）：

var ShowTitle = React.createClass({  getDefaultProps:function(){    return{      title : "React"    }  },  render : function(){    return <h1>{this.props.title}</h1>  }});

React中的props为什么是只读的？

this.props是组件之间沟通的一个接口，原则上来讲，它只能从父组件流向子组件。React具备浓厚的函数式编程的思维。

提到函数式编程就要提一个概念：纯函数。它有几个特点：

  • 给定雷同的输出，总是返回雷同的输入。
  • 过程没有副作用。
  • 不依赖内部状态。

this.props就是吸取了纯函数的思维。props的不能够变性就保障的雷同的输出，页面显示的内容是一样的，并且不会产生副作用

在React中如何防止不必要的render？

React 基于虚构 DOM 和高效 Diff 算法的完满配合，实现了对 DOM 最小粒度的更新。大多数状况下，React 对 DOM 的渲染效率足以业务日常。但在个别简单业务场景下，性能问题仍然会困扰咱们。此时须要采取一些措施来晋升运行性能，其很重要的一个方向，就是防止不必要的渲染（Render）。这里提下优化的点：

  • shouldComponentUpdate 和 PureComponent

在 React 类组件中，能够利用 shouldComponentUpdate或者 PureComponent 来缩小因父组件更新而触发子组件的 render，从而达到目标。shouldComponentUpdate 来决定是否组件是否从新渲染，如果不心愿组件从新渲染，返回 false 即可。

  • 利用高阶组件

在函数组件中，并没有 shouldComponentUpdate 这个生命周期，能够利用高阶组件，封装一个相似 PureComponet 的性能

  • 应用 React.memo

React.memo 是 React 16.6 新的一个 API，用来缓存组件的渲染，防止不必要的更新，其实也是一个高阶组件，与 PureComponent 非常相似，但不同的是， React.memo只能用于函数组件。

React setState 调用之后产生了什么？是同步还是异步？

（1）React中setState后产生了什么

在代码中调用setState函数之后，React 会将传入的参数对象与组件以后的状态合并，而后触发和谐过程(Reconciliation)。通过和谐过程，React 会以绝对高效的形式依据新的状态构建 React 元素树并且着手从新渲染整个UI界面。

在 React 失去元素树之后，React 会主动计算出新的树与老树的节点差别，而后依据差别对界面进行最小化重渲染。在差别计算算法中，React 可能绝对准确地晓得哪些地位产生了扭转以及应该如何扭转，这就保障了按需更新，而不是全副从新渲染。

如果在短时间内频繁setState。React会将state的扭转压入栈中，在适合的机会，批量更新state和视图，达到进步性能的成果。

（2）setState 是同步还是异步的

如果所有setState是同步的，意味着每执行一次setState时（有可能一个同步代码中，屡次setState），都从新vnode diff + dom批改，这对性能来说是极为不好的。如果是异步，则能够把一个同步代码中的多个setState合并成一次组件更新。所以默认是异步的，然而在一些状况下是同步的。

setState 并不是单纯同步/异步的，它的体现会因调用场景的不同而不同。在源码中，通过 isBatchingUpdates 来判断setState 是先存进 state 队列还是间接更新，如果值为 true 则执行异步操作，为 false 则间接更新。

  • 异步： 在 React 能够管制的中央，就为 true，比方在 React 生命周期事件和合成事件中，都会走合并操作，提早更新的策略。
  • 同步： 在 React 无法控制的中央，比方原生事件，具体就是在 addEventListener 、setTimeout、setInterval 等事件中，就只能同步更新。

个别认为，做异步设计是为了性能优化、缩小渲染次数：

  • setState设计为异步，能够显著的晋升性能。如果每次调用 setState都进行一次更新，那么意味着render函数会被频繁调用，界面从新渲染，这样效率是很低的；最好的方法应该是获取到多个更新，之后进行批量更新；
  • 如果同步更新了state，然而还没有执行render函数，那么state和props不能放弃同步。state和props不能放弃一致性，会在开发中产生很多的问题；

React-Router如何获取URL的参数和历史对象？

（1）获取URL的参数

  • get传值

路由配置还是一般的配置，如：'admin'，传参形式如：'admin?id='1111''。通过this.props.location.search获取url获取到一个字符串'?id='1111' 能够用url，qs，querystring，浏览器提供的api URLSearchParams对象或者本人封装的办法去解析出id的值。

  • 动静路由传值

路由须要配置成动静路由：如path='/admin/:id'，传参形式，如'admin/111'。通过this.props.match.params.id 获得url中的动静路由id局部的值，除此之外还能够通过useParams（Hooks）来获取

  • 通过query或state传值

传参形式如：在Link组件的to属性中能够传递对象{pathname:'/admin',query:'111',state:'111'};。通过this.props.location.state或this.props.location.query来获取即可，传递的参数能够是对象、数组等，然而存在毛病就是只有刷新页面，参数就会失落。

（2）获取历史对象

  • 如果React >= 16.8 时能够应用 React Router中提供的Hooks
import { useHistory } from "react-router-dom";let history = useHistory();

2.应用this.props.history获取历史对象

let history = this.props.history;

React-Router的实现原理是什么？

客户端路由实现的思维：

  • 基于 hash 的路由：通过监听hashchange事件，感知 hash 的变动

    • 扭转 hash 能够间接通过 location.hash=xxx

  • 基于 H5 history 路由：

    • 扭转 url 能够通过 history.pushState 和 resplaceState 等，会将URL压入堆栈，同时可能利用 history.go() 等 API
    • 监听 url 的变动能够通过自定义事件触发实现

react-router 实现的思维：

  • 基于 history 库来实现上述不同的客户端路由实现思维，并且可能保留历史记录等，磨平浏览器差别，下层无感知
  • 通过保护的列表，在每次 URL 发生变化的回收，通过配置的 路由门路，匹配到对应的 Component，并且 render

在React中组件的this.state和setState有什么区别？

this.state通常是用来初始化state的，this.setState是用来批改state值的。如果初始化了state之后再应用this.state，之前的state会被笼罩掉，如果应用this.setState，只会替换掉相应的state值。所以，如果想要批改state的值，就须要应用setState，而不能间接批改state，间接批改state之后页面是不会更新的。

React中能够在render拜访refs吗？为什么？

<>  <span id="name" ref={this.spanRef}>{this.state.title}</span>  <span>{     this.spanRef.current ? '有值' : '无值'  }</span></>

不能够，render 阶段 DOM 还没有生成，无奈获取 DOM。DOM 的获取须要在 pre-commit 阶段和 commit 阶段：

React 高阶组件是什么，和一般组件有什么区别，实用什么场景

官网解释∶

高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 本身不是 React API 的一部分，它是一种基于 React 的组合个性而造成的设计模式。

高阶组件（HOC）就是一个函数，且该函数承受一个组件作为参数，并返回一个新的组件，它只是一种组件的设计模式，这种设计模式是由react本身的组合性质必然产生的。咱们将它们称为纯组件，因为它们能够承受任何动静提供的子组件，但它们不会批改或复制其输出组件中的任何行为。

// hoc的定义function withSubscription(WrappedComponent, selectData) {  return class extends React.Component {    constructor(props) {      super(props);      this.state = {        data: selectData(DataSource, props)      };    }    // 一些通用的逻辑解决    render() {      // ... 并应用新数据渲染被包装的组件!      return <WrappedComponent data={this.state.data} {...this.props} />;    }  };// 应用const BlogPostWithSubscription = withSubscription(BlogPost,  (DataSource, props) => DataSource.getBlogPost(props.id));

1）HOC的优缺点

  • 长处∶ 逻辑服用、不影响被包裹组件的外部逻辑。
  • 毛病∶hoc传递给被包裹组件的props容易和被包裹后的组件重名，进而被笼罩

2）实用场景

  • 代码复用，逻辑形象
  • 渲染劫持
  • State 形象和更改
  • Props 更改

3）具体利用例子

  • 权限管制： 利用高阶组件的 条件渲染 个性能够对页面进行权限管制，权限管制个别分为两个维度：页面级别和 页面元素级别
// HOC.jsfunction withAdminAuth(WrappedComponent) {    return class extends React.Component {        state = {            isAdmin: false,        }        async UNSAFE_componentWillMount() {            const currentRole = await getCurrentUserRole();            this.setState({                isAdmin: currentRole === 'Admin',            });        }        render() {            if (this.state.isAdmin) {                return <WrappedComponent {...this.props} />;            } else {                return (<div>您没有权限查看该页面，请分割管理员！</div>);            }        }    };}// pages/page-a.jsclass PageA extends React.Component {    constructor(props) {        super(props);        // something here...    }    UNSAFE_componentWillMount() {        // fetching data    }    render() {        // render page with data    }}export default withAdminAuth(PageA);// pages/page-b.jsclass PageB extends React.Component {    constructor(props) {        super(props);    // something here...        }    UNSAFE_componentWillMount() {    // fetching data    }    render() {    // render page with data    }}export default withAdminAuth(PageB);
  • 组件渲染性能追踪： 借助父组件子组件生命周期规定捕捉子组件的生命周期，能够不便的对某个组件的渲染工夫进行记录∶
class Home extends React.Component {        render() {            return (<h1>Hello World.</h1>);        }    }    function withTiming(WrappedComponent) {        return class extends WrappedComponent {            constructor(props) {                super(props);                this.start = 0;                this.end = 0;            }            UNSAFE_componentWillMount() {                super.componentWillMount && super.componentWillMount();                this.start = Date.now();            }            componentDidMount() {                super.componentDidMount && super.componentDidMount();                this.end = Date.now();                console.log(`${WrappedComponent.name} 组件渲染工夫为 ${this.end - this.start} ms`);            }            render() {                return super.render();            }        };    }    export default withTiming(Home);

留神：withTiming 是利用 反向继承 实现的一个高阶组件，性能是计算被包裹组件（这里是 Home 组件）的渲染工夫。

  • 页面复用
const withFetching = fetching => WrappedComponent => {    return class extends React.Component {        state = {            data: [],        }        async UNSAFE_componentWillMount() {            const data = await fetching();            this.setState({                data,            });        }        render() {            return <WrappedComponent data={this.state.data} {...this.props} />;        }    }}// pages/page-a.jsexport default withFetching(fetching('science-fiction'))(MovieList);// pages/page-b.jsexport default withFetching(fetching('action'))(MovieList);// pages/page-other.jsexport default withFetching(fetching('some-other-type'))(MovieList);

React Hooks 解决了哪些问题？

React Hooks 次要解决了以下问题：

（1）在组件之间复用状态逻辑很难

React 没有提供将可复用性行为“附加”到组件的路径（例如，把组件连贯到 store）解决此类问题能够应用 render props 和 高阶组件。然而这类计划须要从新组织组件构造，这可能会很麻烦，并且会使代码难以了解。由 providers，consumers，高阶组件，render props 等其余形象层组成的组件会造成“嵌套天堂”。只管能够在 DevTools 过滤掉它们，但这阐明了一个更深层次的问题：React 须要为共享状态逻辑提供更好的原生路径。

能够应用 Hook 从组件中提取状态逻辑，使得这些逻辑能够独自测试并复用。Hook 使咱们在无需批改组件构造的状况下复用状态逻辑。 这使得在组件间或社区内共享 Hook 变得更便捷。

（2）简单组件变得难以了解

在组件中，每个生命周期经常蕴含一些不相干的逻辑。例如，组件经常在 componentDidMount 和 componentDidUpdate 中获取数据。然而，同一个 componentDidMount 中可能也蕴含很多其它的逻辑，如设置事件监听，而之后需在 componentWillUnmount 中革除。互相关联且须要对照批改的代码被进行了拆分，而齐全不相干的代码却在同一个办法中组合在一起。如此很容易产生 bug，并且导致逻辑不统一。

在少数状况下，不可能将组件拆分为更小的粒度，因为状态逻辑无处不在。这也给测试带来了肯定挑战。同时，这也是很多人将 React 与状态治理库联合应用的起因之一。然而，这往往会引入了很多抽象概念，须要你在不同的文件之间来回切换，使得复用变得更加艰难。

为了解决这个问题，Hook 将组件中互相关联的局部拆分成更小的函数（比方设置订阅或申请数据），而并非强制依照生命周期划分。你还能够应用 reducer 来治理组件的外部状态，使其更加可预测。

（3）难以了解的 class

除了代码复用和代码治理会遇到困难外，class 是学习 React 的一大屏障。咱们必须去了解 JavaScript 中 this 的工作形式，这与其余语言存在微小差别。还不能遗记绑定事件处理器。没有稳固的语法提案，这些代码十分冗余。大家能够很好地了解 props，state 和自顶向下的数据流，但对 class 却束手无策。即使在有教训的 React 开发者之间，对于函数组件与 class 组件的差别也存在一致，甚至还要辨别两种组件的应用场景。

为了解决这些问题，Hook 使你在非 class 的状况下能够应用更多的 React 个性。 从概念上讲，React 组件始终更像是函数。而 Hook 则拥抱了函数，同时也没有就义 React 的精力准则。Hook 提供了问题的解决方案，无需学习简单的函数式或响应式编程技术