React如何避免重渲染

组件的重新渲染

我们可以在 React 组件中的 props 和 state 存放任何类型的数据,通过改变 props 和 state,去控制整个组件的状态。当 props 和 state 发生变化时,React 会重新渲染整个组件,组件重新渲染的过程可简化如下图:

译者之前对diff的理解是,对于一个改变 props 的组件,diff能自动计算出组件内部DOM树的不同,然后经过对比,找出真正变化的DOM节点,对变化部分进行渲染。这个是错误的理解,diff算法只是用来计算出改变状态或 props的组件/虚拟节点,而这个组件/虚拟节点,无论多大,它都会重新渲染。

假设有一个渲染完成的组件,如下图:

接下来因为状态改变,需要重新渲染下图的绿色的节点,如下图:

一般的想法是只需要更新下面的三个绿色节点就能够完成组件的更新

然而!只要组件的 props 或 state 发生了变化就会重新渲染整个组件,因此除了上述的三个绿色节点以外,还需要重新渲染所有的黄色的节点

除了必要渲染的三个节点外,还渲染了其他不必要渲染的节点,这对性能是一个很大的浪费。如果对于复杂的页面,这将导致页面的整体体验效果非常差。因此要提高组件的性能,就应该想尽一切方法减少不必要的渲染。

shouldComponentUpdate

shouldComponentUpdate这个函数会在组件重新渲染之前调用,函数的返回值确定了组件是否需要重新渲染。函数默认的返回值是 true,意思就是只要组件的 props 或者 state 发生了变化,就会重新构建 virtual DOM,然后使用 diff 算法进行比较,再接着根据比较结果决定是否重新渲染整个组件。函数的返回值为 false 表示不需要重新渲染。

函数默认返回为 true.

PureRenderMixin

React 官方提供了 PureRenderMixin 插件,插件的功能就是在不必要的情况下让函数 shouldComponentUpdate 返回 false, 使用这个插件就能够减少不必要的重新渲染,得到一定程度上的性能提升,其使用方法如下:

  import PureRenderMixin from 'react-addons-pure-render-mixin';
  class FooComponent extends React.Component {
   constructor(props) {
    super(props);
    this.shouldComponentUpdate = PureRenderMixin.shouldComponentUpdate.bind(this);
   }

   render() {
    return <div className={this.props.className}>foo</div>;
   }
  }

我们需要在组件中重写 shouldComponentUpdate,PureRenderMixin源码中对PureRenderMixin.shouldComponentUpdate的定义是这样

  shouldComponentUpdate(nextProps, nextState) {
    return shallowCompare(this, nextProps, nextState);
  }

重写的方法里面根据组件的目前的状态和组件接下来的状态进行浅比较,如果组件的状态发生变化则返回结果为 false,状态没有发生变化则返回结果为 true

  shouldComponentUpdate(nextProps, nextState) {
    return !shallowEqual(this.props, nextProps) ||
        !shallowEqual(this.state, nextState);
  }

在 React 的最新版本里面,提供了 React.PureComponent 的基础类,而不需要使用这个插件。

译者注:所以在一个较大的组件决定重渲染的时候,我们可以在每一个子组件中绑定新的shouldComponentUpdate方法,这样可以减少子组件重新渲染的次数。

我们自己可以重写 shouldComponentUpdate 这个函数,使得其能够对任何事物进行比较,也就是深比较(通过一层一层的递归进行比较),深比较是很耗时的,一般不推荐这么干,因为要保证比较所花的时间少于重新渲染的整个组件所花的时间,同时为了减少比较所花的时间我们应该保证 props 和 state 尽量简单,不要把不必要的属性放入 state,能够由其他属性计算出来的属性也不要放入 state 中。

Immutable.js

对于复杂的数据的比较是非常耗时的,而且可能无法比较,通过使用 Immutable.js 能够很好地解决这个问题,Immutable.js 的基本原则是对于不变的对象返回相同的引用,而对于变化的对象,返回新的引用。因此对于状态的比较只需要使用如下代码即可:

  shouldComponentUpdate() {
    return ref1 !== ref2;
  }

同样需要我们在子组件中将shouldComponentUpdate方法重写。

Pure Component

如果一个组件只和 props 和 state 有关系,给定相同的 props 和 state 就会渲染出相同的结果,那么这个组件就叫做纯组件,换一句话说纯组件只依赖于组件的 props 和 state,下面的代码表示的就是一个纯组件。

   render() {
     return (
       <div style={{width: this.props.width}}>
           {this.state.rows}
       </div>
     );
  }

如果某个子组件的 props 是固定的不会发生变化,我们叫做无状态组件。在这个组件里面使用 pureRenderMixin 插件,能够保证 shouldComponentUpdate 的返回一直为 false。所以,分清纯组件和无状态组件,在无状态组件中重写shouldComponentUpdate方法是最好的选择。

key

在写动态子组件的时候,如果没有给动态子项添加key prop,则会报一个警告。这个警告指的是,如果每一个子组件是一个数组或者迭代器的话,那么必须有一个唯一的key prop,那么这个key prop是做什么的呢?
我们想象一下,假如需要渲染一个有5000项的成绩排名榜单,而且每隔几秒就会更新一次排名,其中大部分排名只是位置变了,还有少部分是完全更新了,这时候key就发挥作用了,它是用来标识当前的唯一性的props。现在尝试来描述这一场景

  [{
   sid: '10001',
   name: 'sysuzhyupeng'
  }, {
   sid: '10008',
   name: 'zhyupeng'
  }, {
   sid: '120000',
   name: 'yupeng'
  }]

其中sid是学号,那么我们来实现成绩排名的榜单

  import React from 'react';
  function Rank({ list }){
    return (
     <ul>
       {list.map((entry, index)=>(
         <li key={index}>{entry.name}</li>
       ))}
     </ul>
    )
  }

我们把key设成了序号,这么做的确不会报警告了,但这样是非常低效的做法,这个key是用来做virtual Dom diff的,上面的做法相当于用了一个随机键,那么不论有没有相同的项,更新都会重新渲染。

正确的做法非常简单,只需要把key的内容换成sid就可以了。

那么还有另一个问题,当key相同的时候,React会怎么渲染呢,答案是只渲染第一个相同key的项,且会报一个警告。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

您可能感兴趣的文章:

  • 详解React项目的服务端渲染改造(koa2+webpack3.11)
  • 从零开始最小实现react服务器渲染详解
  • 基于react后端渲染模板引擎noox发布使用
  • 浅谈React前后端同构防止重复渲染
  • 详解React 在服务端渲染的实现
  • 详解react服务端渲染(同构)的方法
  • 浅谈react前后端同构渲染
  • React如何将组件渲染到指定DOM节点详解
  • React学习笔记之列表渲染示例详解
  • React学习笔记之条件渲染(一)
(0)

相关推荐

  • 浅谈react前后端同构渲染

    前后端同构渲染:当客户端请求一个包含React组件页面的时候,服务端首先响应输出这个页面,客户端和服务端有了第一次交互.然后,如果加载组件的过程需要向服务端发出Ajax请求等,客户端和服务端又进行了一次交互,这样,耗时相对较长.前后端同构渲染可以在页面初次加载时把所有地方渲染好一次性响应给客户端 实现方式:保证包管理工具和模块依赖方式一致 包管理工具-npm管理,保证前后端都使用同一个兼容包 模块依赖方式-webpack,保证前后端都采用commonjs的依赖方式,确保代码可以互相依赖 服务端如

  • React如何将组件渲染到指定DOM节点详解

    前言 众所周知React优点之一就是他的API特别简单.通过render 方法返回一个组件的基本结构,如同一个简单的函数,就可以得到一个可以复用的react组件.但是有时候还是会有些限制的,尤其是他的API中,不能控制组件所应该渲染到的DOM节点,这就让一些弹层组件很难控制.当父元素设置为overflow:hidden 的时候,问题就会出现了. 例如就像下面的这样: 我们实际期待的效果是这样的: 幸运的是,虽然不是很明显,但有一个相当优雅的方式来绕过这个问题.我们学到的第一个react函数是re

  • 浅谈React前后端同构防止重复渲染

    什么叫前后端同构? 为了解决某些问题(比如SEO.提升渲染速度等)react 提供了2个方法在服务端生成一个HTML文本格式的字符串.在得到了这个HTML格式的字符串之后,通常会将其组装成一个页面直接返回给用户的浏览器. 到这里,服务端的活已经干完了,然后就是浏览器这边干活. 浏览器拿到HTML文本后,立刻进行渲染将内容呈现给用户.然后加载页面所需的 .js 文件,然后执行 JavaScript 脚本,然后开始初始化 react 组件---- 到这里问题就来了.react 初始化组件后会执行组件

  • 详解React 在服务端渲染的实现

    React是最受欢迎的客户端 JavaScript 框架,但你知道吗(可以试试),你可以使用 React 在服务器端进行渲染? 假设你已经在客户端使用 React 构建了一个事件列表 app.该应用程序使用了您最喜欢的服务器端工具构建的API.几周后,用户告诉您,他们的页面没有显示在 Google 上,发布到 Facebook 时也显示不出来. 这些问题似乎是可以解决的,对吧? 您会发现,要解决这个问题,需要在初始加载时从服务器渲染 React 页面,以便来自搜索引擎和社交媒体网站的爬虫工具可以

  • React学习笔记之列表渲染示例详解

    前言 本文主要给大家介绍了关于React列表渲染的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 示例详解: 列表渲染也很简单,利用map方法返回一个新的渲染列表即可,例如: const numbers = [1, 2, 3, 4, 5]; const listItems = numbers.map((number) => <li>{number}</li> ); ReactDOM.render( <ul>{listItems}<

  • 详解react服务端渲染(同构)的方法

    学习react也有一段时间了,使用react后首页渲染的速度与seo一直不理想.打算研究一下react神奇服务端渲染. react服务端渲染只能使用nodejs做服务端语言实现前后端同构,在后台对react组件进行解析并生成html字符串后返回视图页面. 后台为什么可以解析react组件?因为Node.js是一个Javascript运行环境,nodejs与javascript语法基本是相同的,所以nodejs可以正常解析react组件. 一.准备动作 1.安装nodejs与安装express 安

  • 基于react后端渲染模板引擎noox发布使用

    React 组件化思想受到越来越多开发者的关注,组件化思想帮助开发者将页面解耦成一个一个组件,代码更加模块化, 更易扩展.而目前流行的后端模板引擎如 ejs, swig, jade, art 共同的问题是: 需要学习各类模板引擎定义的语法,如 {{if}}, {{loop}} 对组件化支持不够强,实现复杂,不易用 针对以上痛点,笔者基于 React 造出了 noox 这样一个工具,专注于后端模板的解析,让模板解析更加简单,易用. 使用方法 安装 npm install noox 简单的 demo

  • React学习笔记之条件渲染(一)

    前言 在React中,你可以创建不同的组件各自封装你需要的东西.之后你可以只渲染其中的一部分,这取决于应用的state(状态).下面就来看看详细的介绍: 条件渲染 可以根据state的值进行组件的条件渲染.例如: function Greeting(props) { const isLoggedIn = props.isLoggedIn; if (isLoggedIn) { return <UserGreeting />; } return <GuestGreeting />; }

  • 详解React项目的服务端渲染改造(koa2+webpack3.11)

    因为对网页SEO的需要,要把之前的React项目改造为服务端渲染,经过一番调查和研究,查阅了大量互联网资料.成功踩坑. 选型思路:实现服务端渲染,想用React最新的版本,并且不对现有的写法做大的改动,如果一开始就打算服务端渲染,建议直接用NEXT框架来写 项目地址:https://github.com/wlx200510/react_koa_ssr 脚手架选型:webpack3.11.0 + react Router4 + Redux + koa2 + React16 + Node8.x 主要

  • 从零开始最小实现react服务器渲染详解

    前言 最近在写 koa 的时候想到,如果我部分代码提供api,部分代码支持ssr,那我应该如何写呢?(不想拆成 2个服务的情况下) 而且最近写的项目里面也用过一些服务端渲染,如nuxt,自己也搭过next的项目,确实开发体验都非常友好,但是友好归友好,具体又是如何实现的呢,诸位有没有考虑过? 本着求真务实的折腾态度,选了react作为研究对象(主要是vue写的有点多,恶心了),那下面就简单就以最小成本写一个react的服务端渲染 demo 用到的技术栈 react 16 + webpack3 +

随机推荐