Мне нравится React. Мне это очень нравится. Я не гений и не Бог Реагирования. Но я живу достаточно долго, поэтому иногда лучший способ узнать что-то - это притвориться, что я что-то знаю, и объяснить это другим ... Итак, я собираюсь притвориться, что знаю о методах жизненного цикла React, чтобы укрепить свои понимание их. Будьте осторожны - я очень профессиональный молодой человек. Но если я буду писать профессиональным тоном, то потеряю много технического жаргона и, возможно, даже усну. Я также не читал статью Джона Доу «10 лучших способов форматирования статьи на Medium». Я буду ближе к делу и, возможно, приведу пару примеров.

Проблема и причина этой статьи

Я изучаю React. Я добавил в закладки документы React на своем телефоне. По иронии судьбы, документацию React больше просматривают на моем компьютере, чем сам Facebook. Некоторые из моих коллег и друзей также изучают React. Среди этих друзей и сверстников я замечаю плач, похожий на плач олененка, которого преследуют по лесу свирепые волки. Однако вместо блеяния крик звучит примерно так: «С какой стати у React есть все эти сложные методы жизненного цикла и чем они, черт возьми, полезны?»

Не волнуйтесь, оленины, идет Логан.

Верно. Логан идет. Перейдем к делу.

Вы знаете цель React?

По словам самого React, React - это «библиотека JavaScript для создания пользовательских интерфейсов».

Это означает, что все, что делает React, должно фильтроваться через эту линзу: пользовательский интерфейс рендеринга. Когда дело доходит до рендеринга пользовательского интерфейса, есть много вопросов, на которые нужно ответить? Вот некоторые из этих вопросов:

Какие данные мы должны отображать? Должны ли мы отображать определенные данные до или после входа пользователя в систему? Следует ли нам дождаться завершения монтажа определенных компонентов, прежде чем рендерить другие компоненты? Насколько взаимосвязаны должны быть все наши компоненты? Что делать, если один из наших компонентов сломается? Что делать, если один из наших компонентов обновляется, но не обновляет состояние? Сколько данных мы должны предварительно кэшировать? Должны ли загружаться только те данные, которые пользователь может сразу увидеть? Как мы должны отображать пользовательский интерфейс в областях с низким уровнем подключения к Интернету?

Список вопросов можно продолжать и продолжать, но я уверен, что вы уловили общую картину. Сейчас мы находимся в мире React, и создание красивого пользовательского интерфейса уже не так просто, как добавить на экран кучу HTML и CSS. По мере того, как браузеры становятся более мощными, а модули узлов сокращаются до размера загрузки в 1 терабайт (уменьшено до 0,98 ТБ), клиент становится значительно более мощным, чем был раньше. Следовательно, способность клиента отображать данные выходит далеко за рамки простого вывода элементов данных на экран. Несмотря на новые движки для клиента и возможности React, мы не можем забывать, что React - это именно то, чем он себя называет - «Библиотека Javascript для создания пользовательских интерфейсов»

Это подводит нас к тому, что я сказал ранее. Основная цель - визуализировать пользовательский интерфейс. Этот пользовательский интерфейс предназначен для обеспечения беспрепятственного и идеального взаимодействия с пользователем приложения React. Чтобы сделать это предсказуемым и управляемым способом, React создает виртуальную модель DOM, а затем подключается к ней. При подключении к DOM React дает нам «ловушки» или организованные, предсказуемые методы, которые помогут нам понять, что, когда и почему определенные события происходят в нашем приложении.

Предсказуемость и цель

React стремится дать нам предсказуемость. Это достигается путем предоставления каждому компоненту возможности управлять своим состоянием. (Я могу сказать больше о том, почему это здорово, но мы вернемся к этому позже)

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

Как лучше всего сделать большое приложение? Сделайте кучу небольших приложений и соберите их вместе. - Тайлер МакГиннис

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

Пример время. Представьте вместе со мной приложение, которое передает нам данные в реальном времени из API погоды. Допустим, это приложение требует, чтобы пользователь ввел 5 своих любимых почтовых индексов, и они могут видеть погоду в режиме реального времени. Допустим, это приложение находится внутри приложения для социальных сетей (назовем его FaceWeather). Это крошечное погодное приложение является лишь частью гораздо более крупного приложения, но оно по-прежнему имеет решающее значение для рендеринга данных. Зададимся вопросом: когда нужно выводить данные о погоде на экран? Помните цель React. Мы надеемся предоставить пользователю невероятный опыт. Мы хотим, чтобы они чувствовали себя едущими на лебеде под полной луной по озеру Тахо посреди осени. Что заставило бы их так себя чувствовать? Время загрузки 30 секунд до истечения времени ожидания и сбоя всего приложения? Или 1,5-секундный экран загрузки, который говорит:
Анкоридж, Аляска
Загрузка…
Затем говорит:
Анкоридж, Аляска
Действительно холодно
Даже разговор о втором результате заставляет меня чувствовать, что я седлаю своего лебедя.

Но вы говорите: «Привет, Логан, это было весело и все такое, но волки все еще преследуют меня, а ты не такой забавный, как ты думаешь». На это я говорю: «Давайте перейдем к техническим вопросам, и моя жена не согласится».

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

До сих пор было сложно четко сформулировать, чего мы хотим, потому что я пытаюсь уточнить два момента. Наши приложения созданы для пользователя, и при ответственном построении React позволяет нам составлять небольшие кусочки пользовательского интерфейса в оркестр приложения. Некоторые из наших компонентов получают API-интерфейсы, некоторые из них просто отображают список, а некоторые из наших компонентов содержат другие компоненты. Жизненный цикл компонента прост: подключение к DOM, выполнение его функции и затем размонтирование. Как я уже говорил, методы жизненного цикла - это перехватчики, которые позволяют нам захватить определенную часть жизненного цикла наших компонентов и выполнить некоторые команды или изменить направление приложения. Я не буду рассматривать их все, но я объясню цели некоторых из наиболее распространенных.

конструктор

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

оказывать

Это реальный рендеринг нашего компонента. Вы могли бы сказать, что это метод нашего компонента «живи бесплатно и упорно умирай». В этом методе может произойти несколько вещей. Он находится вне конструктора, поэтому вы можете инициализировать переменные с заданной областью видимости, переменные для рендеринга или даже выполнять простые или сложные вычисления. Чаще всего в этом методе компонент монтируется в DOM и отображается. Однако вполне возможно, что этот метод вернет значение null или компонент отобразит дочерние элементы на экране.

componentDidMount

Это то, что происходит после нашего метода рендеринга. Там написано: «Эй, я вижу, что вы официально подключены к DOM, вам есть что от меня». Чаще всего вы, вероятно, скажете: «Да, действительно, пожалуйста, принесите мне некоторые данные». На этом этапе он выполнит любые методы или команды, которые вы ему укажете. Этот компонент обычно отправляет запрос на получение некоторому API. Есть несколько причин, по которым это происходит в этом методе, но есть две основные причины, по которым это индивидуальный подход.

1) У вас уже есть весь компонент и все его данные (кроме API), отображаемые на экране. Так что все, чего вы ждете, - это данные. Пользователь, скорее всего, получит несколько значков загрузки, но по большей части основная загрузка компонента завершена, и теперь мы просто ждем, пока данные заполнят поля. Красивый интерфейс без данных по-прежнему остается красивым интерфейсом. Хотя это может быть не так функционально, на меньшем компоненте это не отвлекает. Бесшовное приложение - отличное приложение.

2) Обработка ошибок. Если вы попытаетесь сделать запрос AJAX внутри своего конструктора, вы получите тост. Если вы попытаетесь сделать запрос AJAX внутри вашего метода рендеринга, вы также получите тост. Причина этого проста. Запрос AJAX возвращает обещание. Это означает, что ответ не мгновенный. Я не буду вдаваться в подробности асинхронного и синхронного кода, но достаточно сказать, что запрос не является немедленным. Однако метод рендеринга вызывается сразу после конструктора, независимо от запроса AJAX. Хотя понимание обещания может помочь нам справиться с небольшой ошибкой, делать запрос AJAX в конструкторе по-прежнему небезопасно, потому что до тех пор, пока запрос не будет разрешен, вы на самом деле не знаете, каким будет ответ. И поэтому вы не будете знать, как обрабатывать данные. Если у вас был объект в состоянии под названием «данные», и он должен был быть массивом объектов, и ваш запрос возвратил ошибку 404, у вас есть ошибка, нарушающая работу приложения. На самом деле это не обязательно ошибка 404. Если запрос вернет что-то, кроме ожидаемого, приложение сломается. Однако, если вы уже представили пользовательский интерфейс пользователю, и все, что ему нужно, - это данные (например, твит). Тогда ваш пользователь может застрять с неудобным экраном загрузки только в одном компоненте на экране. Это ничто по сравнению с удалением вашего приложения с Heroku и повторным развертыванием.

Вы определенно не хотите, чтобы этот запрос находился внутри вашего метода рендеринга. Это означает, что запрос будет вызываться каждый раз при вызове setState или при повторном рендеринге родительского компонента. Хотя в некоторых обстоятельствах это может не иметь ничего общего с землей, вы можете представить себе последствия для данных сотового телефона, если бы ваше приложение использовало только одно поле ввода с контролируемым состоянием. Он будет делать запрос каждый раз, когда вы набираете письмо. Даже при правильном регулировании и устранении ошибок ваше приложение начнет заикаться и стонать по мере того, как приложение становится все сложнее. Не говоря уже о том, что ваше состояние, вероятно, будет повторно отображаться каждый раз, когда ваш запрос AJAX будет завершен. Вы бы застряли в бесконечном сетевом запросе! Провайдеры сотовой связи будут любить вас, но, вероятно, будут единственными.

К этому моменту я надеюсь, что убедил вас достаточно в важности componentDidMount.

componentDidUpdate

componentDidMount важен, но он срабатывает только при монтировании вашего компонента и никогда больше. Поэтому, если ваше состояние изменится, ваше приложение может повторно выполнить рендеринг, но больше никогда не будет монтироваться. Это может показаться тривиальным, но что, если вы хотите создать систему нумерации страниц? Или если бы вы были на FaceWeather и получили обновленную информацию об одном из своих постов? Поскольку приложение уже смонтировано, не было бы возможности уведомить вас об этом запросе, если бы не был какой-то способ узнать, обновился ли ваш компонент.

Не так давно я создал систему нумерации страниц для простого приложения для просмотра данных. Он загружал API при подключении и отображал данные на экране. Я хотел, чтобы система была простой. Запрос был достаточно простым, и все, что требовалось, - это типичный «? Page = 2». Попробовав несколько разных способов установить для страницы состояния значение 2, у моего компонента не было возможности узнать, что нужно повторно отправить запрос, поскольку выборка была отправлена ​​в методе componentDidMount. Что мне было нужно? componentDidUpdate. Принцип работы метода прост. Вы сравниваете предыдущее состояние с текущим состоянием (или реквизитами). Если состояния разные, значит, вы знаете, что обновились, и, вероятно, вам следует выполнить какое-то действие. В моем случае я просто сравнил страницу моего текущего состояния со страницей моего предыдущего состояния. Поскольку страница моего текущего состояния теперь была страницей 2, я сказал своему приложению повторно отправить запрос на выборку, но запросить страницу 2 вместо страницы 1. Когда я получил обратно данные, мой компонент отрисовался повторно, и я так сильно плакал с радость, что вы могли подумать, что родители Гарри Поттера вернулись к жизни, чтобы научить своих внуков магии.

componentWillUnmount

Это действительно просто. Он вызывается прямо перед удалением вашего компонента из DOM. Это полезно для остановки действий, которые необходимо выполнить, когда компонент отключен. Например, если у вас есть часы, работающие вне window.setInterval, вам, вероятно, следует очистить интервал при размонтировании, прежде чем взорвать чей-то компьютер. Или, если у вас есть компонент, воспроизводящий музыку, было бы неплохо прекратить воспроизведение музыки, когда пользователь щелкает «x» на указанном компоненте. Это можно сделать с помощью простого «componentWillUnMount». Кажется, что этот метод жизненного цикла почти не требует объяснений или может быть ненужным, но он может иметь решающее значение для создания высокопроизводительного программного обеспечения.

Некоторые последние мысли

Хотя я знаю, что, возможно, я разглагольствовал, бредил и, вероятно, полностью упустил весь смысл написания этой статьи, я надеюсь, что она была сочтена кому-то ценной. Я, конечно, не эксперт в этой области, и вполне возможно, что в этой статье есть вещи, которые неверны или нуждаются в пояснении. Моя цель просто заключалась в том, чтобы поместить достаточно моих бессвязных мыслей в какую-то связную статью, чтобы это могло быть полезно для моих друзей, изучающих React. На самом деле, я бы посоветовал вам прочитать эту статью - › https://engineering.musefind.com/react-lifecycle-methods-how-and-when-to-use-them-2111a1b692b1

Вышеупомянутая статья хорошо написана и предоставляет более подробные примеры методов жизненного цикла компонентов React.

Это была моя первая статья на Medium, и, как и мой первый компонент React, она была беспорядочной и неорганизованной, но чертовски весело. Если у вас есть отзывы, я хотел бы их услышать. Однако, если вы собираетесь указать на опечатку, вы, вероятно, теперь должны знать, что я собираюсь найти ваш Reddit и пометить все ваши сообщения как спам.

Подробнее откуда это взялось

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

Следите за нашей публикацией, чтобы увидеть больше статей, представленных командой Журнала.