Translate

Поиск по этому блогу

воскресенье, 13 мая 2018 г.

React.js (7) shouldComponentUpdate(). Оптимизация.

Теперь давайте разберемся с методом, который мы не стали подробно разбирать при изучении жизненного цикла компонентов. Это метод shouldComponentUpdate - который позволяет оптимизировать React- компоненты.


Все статьи по React.js



Давайте посмотрим как ведет себя React без него. В файле Article.js. У нас в этом файле слишком много различных выводов данных в консоль (console.log()).

Часть из них, например - в componentWillReceiveProps(nextProps) и в функции handleClick , мы уберем и посмотрим, что происходит тогда, когда мы хотим поменять порядок статей.

Мы нажимаем на кнопку и у нас семь раз (!!!) перестраивается порядок наших статей component will update.

См.фото ниже.



Это означает, что перестраивается каждая из этих статей. На самом деле нам достаточно было бы открыть одну статью (верхнюю) и закрыть другую (нижнюю). Статьи которые находятся посередине просто поменялись местами, но внутри них ничего не изменилось.

Конечно, в реальном DOM эти изменения не будут отображаться, но тем не менее можно бы было обойтись и без лишних перестроений виртуального DOM. Для этого нам и потребуется shouldComponentUpdate(). Давайте посмотрим как он работает.

Изначально наше виртуальное дерево выглядело так (для первых трех статей):



У нас открыта первая статья и закрыты все остальные.

Мы нажимаем на кнопку Revert и будем перестраивать виртуальный DOM.



Для этого в ArticleList передадим массив в перевернутом порядке и для каждой статьи начнем обновлять виртуальный DOM.

Мы зайдем в первую статью, там ничего не поменялось, но она стала открытой и соответственно нам нужно поменять текст на кнопке и нужно добавить секцию с текстом.

См. фото ниже.



Затем мы пойдем во вторую статью. в ней ничего не поменялось, но перестроим виртуальный DOM, чтобы сравнить. таким образом мы пойдем, и в третью, и в четвертую, и т.д. Для каждой их них мы будем перестраивать виртуальный DOM, понимая. что ничего не изменилось но идти дальше.

Так мы дойдем до последней статьи, где нужно поменять текст на кнопке и убрать секцию



Таким образом изменения в реальном DOM коснутся только первой и последней статьи. а виртуальный DOM будет перестраиваться для всех остальных.

И это абсолютно нормальное поведение React по умолчанию. Он не делает никаких предположений о ваших данных. Он не знает какие данные влияют на компонент. Он даже не знает какие данные поменялись у вас в системе.

Единственное что его интересует это как ваше приложение выглядело до обновления и как оно должно выглядеть после. То есть - какие изменения нужно сделать. Однако, мы зная особенности наших компонентов. особенности бизнес-логики можем помочь React и подсказать, что в некоторых случаях перестраивать компоненты необязательно. Для этого нам необходимо реализовать на компоненте метод shouldComponentUpdate()

Предположим. что мы знаем, что на наш компонент сейчас может повлиять только то открыт он или закрыт. То есть состояние isOpen: true / false. Соответственно, мы можем сравнить старое состояние с новым, понять поменялось ли что-либо и принять решение - нужно ли нам перестраивать данный компонент или нет.

Давайте посмотрим как это работает.

При этом ArticleList, когда будет перестраивать виртуальный DOM, он будет "спрашивать" у компонента - нужно ли его перестроить, вызывая на нем shouldComponentUpdate().

Если он вернет true, то он зайдет, сравнит и внесет изменения.

Затем пойдет в следующую статью и вызовет у нее shouldComponentUpdate() и если вернет false, то он просто пропустит ее. Не будет заходить и перестраивать виртуальный DOM и тем более ничего не станет менять в реальном DOM. Он просто пойдет дальше.

Если статья вернет true, то пойдет и поменяет в ней виртуальный DOM и внесет все необходимые изменения в реальную структуру.

см фото ниже



Таким образом мы перестроим виртуальный DOM только для первой и последней статьи.

Давайте это реализуем.

Идем в файл Article.js


  shouldComponentUpdate(nextProps, nextState) {
    return this.state.isOpen !== nextState.isOpen
  }



Здесь мы будем следить за состоянием (открыто \ закрыто). Функция вернет true или false в зависимости от того, поменялось ли состояние.

Проверяем.



Теперь will update вызывается всего два раза!все равно сколько раз бы мы не меняли порядок. Почему так происходит?. Потому что для "внутренних" статей у нас ничего не меняется.

Но у такой реализации shouldComponentUpdate() есть опасность!

предположим, что у нас появляются какие-либо еще интересующие нас данные. Например: Мы хотели бы посчитать количество кликов по заголовку.

Для этого мы повесили бы на заголовок hendler

Article.js

  import React, {Component} from 'react'

  class Article extends Component {
    constructor(props) {
      super(props)

      this.state = {
        isOpen: props.defaultOpen,
        count: 0
      }
    }
    shouldComponentUpdate(nextProps, nextState) {
      return this.state.isOpen !== nextState.isOpen

    }

    componentWillMount() {
      console.log('---','mounting')
    }

    componentWillReceiveProps(nextProps) {
      if(nextProps.defaultOpen !== this.props.defaultOpen) this.setState({
        isOpen: nextProps.defaultOpen
      })
    }
    componentWillUpdate() {
      console.log('---','component will update')
      
    }

    render() {
        const {article} = this.props
        const style = {width:'50%'}
        const body = this.state.isOpen && <section className="card-text">{ article.text }</section> 
      return(
        <div className="card mx-auto" style={style}>
          <div className="card-header">
            <h2 onClick={this.incrementCounter}>
                { article.title }
                clicked {this.state.count}
                <button onClick={this.handleClick} className="btn btn-primary btn-lg float-right">
                    {this.state.isOpen ? 'close' : 'open'}
                </button>
            </h2>
          </div>
          <div className="card-body"> 
                <h6 className="card-subtitle text-muted">
                   "creation date : "{ (new Date(article.date)).toDateString()}
                </h6>
                { body }
          </div>
        </div>
      );
    }
    incrementCounter = () => {
      this.setState({
        count: this.state.count + 1
      })
    }

    handleClick = () =>{
     
      this.setState({
        isOpen: !this.state.isOpen
      })
    }
  }

  export default Article



Теперь у нас появилась возможность считать клики по кнопке, но если нажимать кнопку с удержанием, то тогда появится пескакивание счета на несколько единиц.



Почему так происходит? Потому что мы делали предположения только про isOpen

Теперь нам нужно принимать во внимание еще и count. Следить за изменением такой функциональности достаточно неудобно. Поэтому чаще всего shouldComponentUpdate() реализуют другим способом.

Сравнивая все props старый с новыми и все элементы state. и если у нас поменяется хоть одно, то компонент будет перестраиваться. Если нет, то тогда все без изменений.

Этот подход настолько распространенный, что для него есть даже отдельный компонент PureComponent в React (мы его и добавим) в импорт и унаследуем Article от него, то нам не придется реализовывать shouldComponentUpdate(), как ранее.

то есть вот эту часть можно будет убрать.
Article.js

    shouldComponentUpdate(nextProps, nextState) {
      return this.state.isOpen !== nextState.isOpen

    }




Article.js

  import React, {Component, PureComponent} from 'react'

  class Article extends PureComponent {
    constructor(props) {
      super(props)

      this.state = {
        isOpen: props.defaultOpen,
        count: 0
      }
    }

    // shouldComponentUpdate(nextProps, nextState) {
    //   return this.state.isOpen !== nextState.isOpen

    // }

    componentWillMount() {
      console.log('---','mounting')
    }

    componentWillReceiveProps(nextProps) {
      if(nextProps.defaultOpen !== this.props.defaultOpen) this.setState({
        isOpen: nextProps.defaultOpen
      })
    }
    componentWillUpdate() {
      console.log('---','component will update')
      
    }

    render() {
        const {article} = this.props
        const style = {width:'50%'}
        const body = this.state.isOpen && <section className="card-text">{ article.text }</section> 
      return(
        <div className="card mx-auto" style={style}>
          <div className="card-header">
            <h2 onClick={this.incrementCounter}>
                { article.title }
                clicked {this.state.count}
                <button onClick={this.handleClick} className="btn btn-primary btn-lg float-right">
                    {this.state.isOpen ? 'close' : 'open'}
                </button>
            </h2>
          </div>
          <div className="card-body"> 
                <h6 className="card-subtitle text-muted">
                   "creation date : "{ (new Date(article.date)).toDateString()}
                </h6>
                { body }
          </div>
        </div>
      );
    }
    incrementCounter = () => {
      this.setState({
        count: this.state.count + 1
      })
    }

    handleClick = () =>{
     
      this.setState({
        isOpen: !this.state.isOpen
      })
    }
  }

  export default Article




PureComponent отличается от обычного Component тем, что у него уже изначально реализовано - shouldComponentUpdate(nextProps, nextState), который изначально сравнивает все элементы props и все элементы state.

Таким образом будут работать все наши клики по заголовку и при этом если мы захотим поменять порядок статей у нас будет изменять всего две статьи - верхняя и нижняя.

Таким образом с помощью компонента shouldComponentUpdate мы можем оптимизировать наше приложение.

Тем не менее этим не следует злоупотреблять!

Как и любая другая оптимизация она должна применяться с умом!

PureComponent - может помочь оптимизировать наше приложение в тех местах, где это необходимо, но если вы будете расставлять его по всему приложение. то вы рискуете получить проблемы. Это возможно если ваш компонент зависит не только от props и state, или какой - либо дочерний элемент зависит не только от props и state, а окажется так, что вы этого не знали, то соответственно можете получить ряд багов, которые потом трудно будет искать и исправлять.

Вывод - используйте PureComponent только по назначению не злоупотребляя им!

Все статьи по React.js



Файлы, которые мы изменяли в этот раз:


Article.js (я его привел полностью со всеми изменениями этого поста выше)
                                                                                                                                                             

Комментариев нет:

Отправить комментарий



Хотите освоить самые современные методы написания React приложений? Надоели простые проекты? Нужны курсы, книги, руководства, индивидуальные занятия по React и не только? Хотите стать разработчиком полного цикла, освоить стек MERN, или вы только начинаете свой путь в программировании, и не знаете с чего начать, то пишите через форму связи, подписывайтесь на мой канал в Телеге, вступайте в группу на Facebook.Пишите мне - kolesnikovy70 почта gmail.com