Зачем использовать getDerivedStateFromProps вместо componentDidUpdate?

Как говорится в этом деле React Github, я все больше вижу, что

стоимость render() относительно небольшая

В React 16.3 мне интересно, почему можно использовать новые getDerivedStateFromProps вместо componentDidUpdate?

Представьте себе этот пример:

getDerivedStateFromProps(nextProps, prevState) {
  if (!prevState.isModalOpen && nextProps.isReady) {
       return { isModalOpen: true };
  }
}

против

componentDidUpdate(prevProps, prevState) {
  if (!prevState.isModalOpen && this.props.isReady) {
        this.setState({ isModalOpen: true });
  }
}

Позднее кажется проще, потому что он использует только существующий API и выглядит так же, как то, что мы делали в компонентах componentWillReceiveProps, поэтому я не понимаю, почему пользователи будут искать getDerivedStateFromProps? Какая польза?

Спасибо!

Ответ 1

Так что Дэн Абрамов ответил на Твиттер, и кажется, что есть две причины, почему вы должны использовать getDerivedStateFromProps вместо componentDidUpdate + setState:

setState в компонентеDidUpdate вызывает дополнительный рендеринг (не воспринимается напрямую для пользователя, но замедляет ваше приложение). И вы производите метод can not, чтобы состояние было готово (потому что оно не будет в первый раз).

Причина исполнения: она позволяет избежать ненужной повторной обработки.
Поскольку getDerivedStateFromProps вызывается перед рендерингом в init, вы можете инициализировать свое состояние в этой функции вместо того, чтобы иметь конструктор для этого. В настоящее время у вас должен быть конструктор или componentWillMount для инициализации вашего состояния до первоначального рендеринга.

Ответ 2

getDerivedStateFromProps фактически заменяет componentWillReceiveProps а componentDidMount не будет устаревшим.

Я почти уверен, что именно сообщество решило создать статический метод с этим именем.

Причиной этого изменения является то, что componentWillReceiveProps был одним из методов, который привел к путанице и дальнейшим утечкам памяти в пользовательских приложениях:

Многие из этих проблем усугубляются подмножеством жизненных циклов компонента (componentWillMount, componentWillReceiveProps и componentWillUpdate). Они также являются жизненными циклами, которые вызывают наибольшую путаницу в сообществе React. По этим причинам мы будем осуждать эти методы в пользу лучших альтернатив.

Здесь твит Дэн Абрамов, который также делает это более ясным:

Однако это означает, что мы хорошо разделяем наши пути с компонентомWillReceiveProps() в 17. Мы считаем, что getDerivedStateFromProps() делает ту же работу лучше и менее запутанной. Также случается, что cWRP() действительно испортит наши планы по извлечению данных, которые могут быть в конвейере. 🙂