Почему документы React рекомендуют делать AJAX в componentDidMount, а не componentWillMount?

Question

Почему документы React рекомендуют делать AJAX в componentDidMount, а не componentWillMount?

94

Название говорит все. Я понимаю, почему componentDidMount подходит для всего, что требует доступа DOM, но запрос AJAX не обязательно или обычно нуждается в этом.

Что дает?

Alan H. 26 нояб. 2014, в 01:19

Источник

0

@FurkanO Я думаю, что он имел в виду доступ к элементам DOM, отображаемым компонентом. И он совершенно прав, потому что, если вы попытаетесь получить доступ к указанным элементам в componentWillMount он потерпит неудачу, учитывая, что компонент ... не смонтирован.
ZekeDroid 07 дек. 2016, в 17:10
0

@AlanH. Удалил мой вопрос, конечно у вас есть доступ к dom на componentDidMount. Это правило, ничего не объяснять. Благодарю.
FurkanO 28 дек. 2016, в 22:20
0

По моему мнению, именно поэтому мы вызываем функцию Ajax после componentDidMount, мы должны сначала убедиться, что элемент рендерится плавно в начале. После этого мы можем сделать вызов ajax. Если мы сначала вызываем ajax и происходит ошибка, это вызовет проблемы при рендеринге.
Faris Rayhan 09 март 2018, в 22:29

Показать ещё 1 комментарий

Теги:

reactjs

3 ответа

34

У меня была такая же проблема и в начале. Я решил попробовать сделать запросы в componentWillMount, но в конечном итоге это связано с небольшими проблемами.

Я запускал рендеринг, когда вызов ajax заканчивается новыми данными. В какой-то момент рендеринг компонента занял больше времени, чем получение ответа от сервера, и на этом этапе обратный вызов ajax вызывал рендеринг на немонтированном компоненте. Это своего рода краевой кейс, но, вероятно, больше, поэтому безопаснее придерживаться componentDidMount.

daniula 26 нояб. 2014, в 01:48

0

Хорошо спасибо. Думал, что это может быть что-то подобное, но вы правы, удивительно, что запрос ajax может закончиться раньше, чем это сделает рендер.
Alan H. 26 нояб. 2014, в 06:22
1

@daniula Вы уверены? Как завершить запрос AJAX перед рендерингом?
Leon Grapenthin 20 дек. 2015, в 20:06
4

Это браузерный асинхронный мир. Никогда не думайте, что одна функция всегда будет быстрее остальных. Как я уже упоминал, это крайний случай и, вероятно, означает, что вам следует оптимизировать процесс рендеринга, но использование правильного метода жизненного цикла в этот момент значительно облегчит вашу жизнь.
daniula 21 дек. 2015, в 09:28
0

как насчет конструктора класса es6? Является ли конструктор тем же с componentDidMount?
SooCheng Koh 06 июнь 2016, в 08:41
1

@SooChengKoh Конструктор класса ES6 эквивалентен componentWillMount , поэтому вы все равно должны продолжать использовать componentDidMount для вызовов ajax.
daniula 06 июнь 2016, в 12:48
1

@SooChengKoh - Определенно не следует делать ничего в конструкторе, что приведет к состоянию, которое должно быть установлено, что приведет к условиям гонки на клиенте и сервере. Вы никогда не должны вызывать setState в конструкторе компонентов, и у вас нет возможности определить, когда завершится вызов AJAX. twitter.com/dan_abramov/status/576453138598723585
cchamberlain 17 сен. 2016, в 15:44
0

может быть, вы можете следить за вашей функцией Ajax с ожиданием. Это то, что моя команда сделала в разработке.
Faris Rayhan 09 март 2018, в 22:32

Показать ещё 5 комментариев

3

В соответствии с настройкой документации состояние в componentWillMount не приведет к повторному рендерингу. Если вызов AJAX не блокируется, и вы возвращаете Promise, которые обновляют состояние компонента при успешном выполнении, есть вероятность, что ответ будет получен после того, как компонент будет визуализирован. Поскольку componentWillMount не запускает повторную визуализацию, у вас не будет ожидаемого поведения, которое будет отображаться компонентом с запрошенными данными.

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

Gabriel Grigelmo Mecerreyes 11 апр. 2017, в 09:47

0

componentWillMount не запускает повторную визуализацию только потому, что новое состояние определяется перед первой визуализацией. Но если setState вызывается в setState вызове AJAX, он будет определенно вызываться после первого рендеринга и будет вызывать ре-рендеринг.
webdif 07 сен. 2017, в 15:38

Ещё вопросы

@FurkanO Я думаю, что он имел в виду доступ к элементам DOM, отображаемым компонентом. И он совершенно прав, потому что, если вы попытаетесь получить доступ к указанным элементам в componentWillMount он потерпит неудачу, учитывая, что компонент ... не смонтирован.
@AlanH. Удалил мой вопрос, конечно у вас есть доступ к dom на componentDidMount. Это правило, ничего не объяснять. Благодарю.
По моему мнению, именно поэтому мы вызываем функцию Ajax после componentDidMount, мы должны сначала убедиться, что элемент рендерится плавно в начале. После этого мы можем сделать вызов ajax. Если мы сначала вызываем ajax и происходит ошибка, это вызовет проблемы при рендеринге.
Хорошо спасибо. Думал, что это может быть что-то подобное, но вы правы, удивительно, что запрос ajax может закончиться раньше, чем это сделает рендер.
@daniula Вы уверены? Как завершить запрос AJAX перед рендерингом?
Это браузерный асинхронный мир. Никогда не думайте, что одна функция всегда будет быстрее остальных. Как я уже упоминал, это крайний случай и, вероятно, означает, что вам следует оптимизировать процесс рендеринга, но использование правильного метода жизненного цикла в этот момент значительно облегчит вашу жизнь.
как насчет конструктора класса es6? Является ли конструктор тем же с componentDidMount?
@SooChengKoh Конструктор класса ES6 эквивалентен componentWillMount , поэтому вы все равно должны продолжать использовать componentDidMount для вызовов ajax.
@SooChengKoh - Определенно не следует делать ничего в конструкторе, что приведет к состоянию, которое должно быть установлено, что приведет к условиям гонки на клиенте и сервере. Вы никогда не должны вызывать setState в конструкторе компонентов, и у вас нет возможности определить, когда завершится вызов AJAX. twitter.com/dan_abramov/status/576453138598723585
может быть, вы можете следить за вашей функцией Ajax с ожиданием. Это то, что моя команда сделала в разработке.
componentWillMount не запускает повторную визуализацию только потому, что новое состояние определяется перед первой визуализацией. Но если setState вызывается в setState вызове AJAX, он будет определенно вызываться после первого рендеринга и будет вызывать ре-рендеринг.

FakeRainBrigand · Accepted Answer · 2014-11-26T02-03-00.000Z

60

Лучший ответ

componentDidMount для побочных эффектов. Добавление прослушивателей событий, AJAX, мутация DOM и т.д.

componentWillMount редко бывает полезным; особенно если вы заботитесь о рендеринге на стороне сервера (добавление прослушивателей событий вызывает ошибки и утечки, а также множество других вещей, которые могут пойти не так).

Говорят об удалении componentWillMount из компонентов класса, поскольку он выполняет ту же задачу, что и конструктор. Он останется на компонентах createClass.

FakeRainBrigand 26 нояб. 2014, в 02:03

1

Добавление прослушивателей событий приводит к ошибкам и утечкам все время на сервере или только в componentWillMount ? Я не вижу различия.
Alan H. 26 нояб. 2014, в 06:22
18

@Alan - Если вы используете React как на стороне клиента, так и на стороне сервера, вы обнаружите, что все, что находится внутри componentWillMount будет выполняться при рендеринге на стороне сервера. Если бы вы использовали componentDidMount то это было бы выполнено только на стороне клиента. В результате помещение в componentWillMount вещей, которые выполняют внешние взаимодействия или привязываются к событиям и т. Д., Не является хорошей идеей. Если вы не планируете рендерить свои компоненты на стороне сервера, это все еще не очень хорошая идея только для потенциальной переносимости кода. Это все за пределами основной причины, по которой это плохо, что объясняется в ответе @daniula.
Mike Driver 26 нояб. 2014, в 11:32
3

componentWillMount запускается на сервере, а componentWillUnmount (где вы удаляете слушателей) - нет. Это заставит вас добавлять слушателей и никогда не очищать их.
FakeRainBrigand 26 нояб. 2014, в 11:53
0

Сотрудники основной команды React рассматривают возможность удаления componentWillMount из будущих версий.
cchamberlain 17 сен. 2016, в 15:38
0

@cchamberlain обновлен, спасибо.
FakeRainBrigand 17 сен. 2016, в 17:01
0

@FakeRainBrigand это нормально делать сетевые вызовы в конструкторе?
aks 23 фев. 2017, в 05:45
0

@AnkitSinghaniya Нет, сделай их в Дидмаунте.
FakeRainBrigand 23 фев. 2017, в 20:52
0

@FakeRainBrigand Прошу прощения за наивность, но вы можете сказать мне, в чем причина этого?
aks 24 фев. 2017, в 04:47
1

@AnkitSinghaniya это нарушит рендеринг сервера и мелкие юнит-тесты.
FakeRainBrigand 24 фев. 2017, в 18:27
0

@FakeRainBrigand, не могли бы вы поделиться ссылкой на доклад о предложении отказаться от компонента WillMount?
Nima Mehanian 23 окт. 2017, в 23:03
0

@NimaMehanian github.com/facebook/react/issues/7671
FakeRainBrigand 24 окт. 2017, в 02:53

Показать ещё 9 комментариев