Почему компонентWillMount не должен использоваться?

Ответ 1

Чтобы привести @Дан Абрамов

В будущих версиях React мы ожидаем, что компонент componentWillMount будет срабатывать более одного раза в некоторых случаях, поэтому вы должны использовать componentDidMount для сетевых запросов.

Подробнее здесь.

Ответ 2

ОБНОВЛЕНИЕ - май /2018
В процессе работы появилась новая функция, которая называется асинхронный рендеринг.
На момент реакции v16.3.2 эти методы не являются "безопасными" для использования:

• componentWillMount
• componentWillReceiveProps
• componentWillUpdate

Вы можете прочитать больше об этом в документации.

Как правило , не используйте componentWillMount вообще (если вы используете синтаксис class es6). используйте вместо этого метод constructor.
Этот метод жизненного цикла хорош для инициализации состояния синхронизации.
componentDidMount другой стороны, componentDidMount хорош для манипулирования асинхронным состоянием.

Почему?
Что ж, когда вы делаете асинхронный запрос в constructor/componentWillMount вы делаете это до render будет вызван render, к тому времени, когда асинхронная операция закончила, метод render скорее всего, уже завершен, и на этом этапе нет смысла устанавливать "начальное состояние" Это?.
Я не уверен, что это ваш случай, но в большинстве случаев разработчики хотят асинхронно инициировать состояние в componentWillMount, чтобы избежать повторного вызова render. но вы не можете избежать этого, можете, как упоминалось выше, render все равно сработает до завершения асинхронной операции.
Итак, лучшее время для вызова асинхронной операции - после вызова render и монтирования компонента (вы можете смонтировать null или пустой <div/>), а затем получить ваши данные, установить состояние и сделать его повторный рендеринг соответственно.

Ответ 3

componentDidMount - лучшее место для вызова вызовов для извлечения данных по двум причинам:

• Использование componentDidMount позволяет понять, что данные не будут загружены до первого рендера. Вам нужно правильно настроить начальное состояние, поэтому вы не получите состояние undefined, которое вызывает ошибки.

• Если вам нужно отобразить приложение на сервере, componentWillMount будет вызываться дважды (на сервере и снова на клиенте), что, вероятно, не то, что вы хотите. Ввод кода загрузки данных в componentDidMount гарантирует, что данные будут получены только от клиента. Как правило, вы не должны добавлять побочные эффекты к componentWillMount.

Ответ 4

Как я понимаю, одна из самых больших причин связана с настройкой правильных ожиданий разработчиков, считывающих код.

Если мы используем componentWillMount, соблазн подумать, что выборка успевает, тогда компонент "сделал", а затем первый рендер будет выполнен. Но это не так. Если мы выполняем асинхронный вызов (например, вызов API с помощью Promises), компонент будет фактически запускать render до того, как выборка сможет вернуться и установить состояние компонента (или изменить состояние Redux или что когда-либо).

Если мы вместо этого используем componentDidMount, тогда ясно, что компонент будет выдавать хотя бы один раз, прежде чем вы получите какие-либо данные (поскольку компонент уже сделал mount). Таким образом, по расширению также ясно, что мы должны обрабатывать начальное состояние таким образом, чтобы компонент не разбивался на первый ( "пустой" ) рендер.

Ответ 5

Жизненный цикл монтажа компонентов

• конструктор()
• componentWillMount()/UNSAFE_componentWillMount() (реакция 16)
• рендеринга()
• componentDidMount()

Constructor и componentWillMount оба вызывают перед вызовом render(), который отвечает за отображение страницы.

Здесь инициализированное состояние выполняется в конструкторе, а api вызывается в componentDidMount из-за асинхронных вызовов.

ComponentWillMount был хорош для инициализированного состояния до ES6, когда конструктора не было. Но теперь ComponentWillMount ни на что не годится, и команда реагирует на это после реакции 17.

В дополнение к вышесказанному, реагирование перешло к архитектуре реагирования по волокну, чтобы избежать ненужного повторного рендеринга и повышения производительности, реагирование решило отказаться от методов componentWillMount, componentWillReciveProps и componentWillUpdate.