В сегодняшней части перевода учебного курса по React вашему вниманию будет представлен обзор методов жизненного цикла компонентов.
> Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
> Часть 2: функциональные компоненты
> Часть 3: файлы компонентов, структура проектов
> Часть 4: родительские и дочерние компоненты
> Часть 5: начало работы над TODO-приложением, основы стилизации
> Часть 6: о некоторых особенностях курса, JSX и JavaScript
> Часть 7: встроенные стили
> Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
> Часть 9: свойства компонентов
> Часть 10: практикум по работе со свойствами компонентов и стилизации
> Часть 11: динамическое формирование разметки и метод массивов map
> Часть 12: практикум, третий этап работы над TODO-приложением
> Часть 13: компоненты, основанные на классах
> Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
> Часть 15: практикумы по работе с состоянием компонентов
> Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
> Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
> Часть 18: шестой этап работы над TODO-приложением
> Часть 19: методы жизненного цикла компонентов
> Часть 20: первое занятие по условному рендерингу
App.js
которого содержится следующий код:import React, {Component} from "react"
class App extends Component {
constructor() {
super()
this.state = {}
}
render() {
return (
<div>
Code goes here
</div>
)
}
}
export default App
render()
.render()
в процессе жизни компонента может быть вызван множество раз. Так, когда React определяет, что что-то, относящееся к компоненту, изменилось, наподобие состояния или свойств, то есть что-то такое, что может повлиять на внешний вид компонента, React может вызвать этот метод. Это можно сравнить, если продолжить аналогию с людьми, с тем, что человек может решить переодеться. Например для того, чтобы, после рабочего дня, подготовиться к некоему праздничному мероприятию.componentDidMount()
. Этот метод объявляют, точно так же, как и любые другие методы компонентов, основанных на классах, в теле класса компонента:componentDidMount() {
}
componentDidMount()
вызван не будет. Происходит это из-за того, что при выполнении подобных операций не производится изъятие компонента из дерева DOM и его последующее повторное включение в состав дерева.componentDidMount()
обычно используют для выполнения обращений к неким API, в случаях, когда разработчику нужны данные из внешних источников. Предположим, компонент, который мы тут рассматриваем, на самом деле называется TodoList
и представляет собой компонент, формирующий список дел в Todo-приложении. Метод componentDidMount()
такого компонента может выполнять загрузку материалов из серверной базы данных, необходимых для корректного вывода на страницу хранящегося на сервере списка дел. В результате после того, как монтирование компонента завершено, мы, в методе componentDidMount()
, можем загрузить данные, необходимые для правильного отображения компонента на странице. Мы ещё поговорим о загрузке данных, необходимых компонентам, а пока же можете запомнить, что это — наиболее часто встречающийся вариант использования метода componentDidMount()
.componentWillReceiveProps()
. Этот метод можно сравнить с тем, что происходит, когда кто-то получает от кого-то подарок. Так, компонент может получать свойства от родительского компонента. Каждый раз, когда компонент принимает свойства, вызывается этот метод. При этом данный метод вызывается каждый раз, когда родительский компонент передаёт свойства дочернему компоненту, а не только тогда, когда это случается в первый раз. Например, если родительский компонент решит поменять свойства, переданные дочернему компоненту, то мы, в методе componentWillReceiveProps()
, сможем, например, проверить, отличаются ли новые свойства от тех, что уже были переданы компоненту. Дело в том, что если новые свойства не отличаются от старых, это значит, что их поступление ничего не меняет, а значит — мы можем, выяснив это, больше ничего не делать. Если же новые свойства отличаются от старых, мы можем выполнить некие действия. Обычно этот метод объявляют в теле класса компонента в таком виде:componentWillReceiveProps(nextProps) {
}
nextProps
, но назвать этот параметр можно как угодно. Для того чтобы сравнить некое конкретное свойство, которое уже было передано компоненту, с тем, что уже было ему передано ранее, и принять решение о дальнейших действиях, можно воспользоваться такой конструкцией:componentWillReceiveProps(nextProps) {
if (nextProps.whatever !== this.props.whatever) {
// сделать тут что-то важное
}
}
componentWillReceiveProps()
— это один из таких методов.UNSAFE_componentWillReceiveProps()
. После выхода React 17 имя метода componentWillReceiveProps()
не будет означать ничего особенного.shouldComponentUpdate()
. Он, если продолжить сравнение компонента с человеком, напоминает момент, когда человек размышляет о том, надо ли ему переодеться или нет. В обычных условиях, если React не вполне уверен в том, надо ли повторно отрендерить компонент, он его, на всякий случай, всё же отрендерит. При этом неважно — нужно ли это, в соответствии с логикой приложения, или нет.shouldComponentUpdate()
даёт разработчику возможность оптимизировать приложение. Здесь можно реализовать некую логику, помогающую выяснить необходимость обновления компонента. Этот метод обычно объявляют так:shouldComponentUpdate(nextProps, nextState) {
// вернуть true если компонент нуждается в обновлении
// вернуть false в противном случае
}
true
. В противном случае из него нужно вернуть false
. Собственно говоря, возврат false
из этого метода приводит к тому, что обновление компонента не выполняется и приложение работает быстрее, но, делая это, нужно быть уверенным в том, что компоненту действительно не требуется повторный рендеринг. Если же компоненту нужно обновиться, а этот метод вернул false
— это приведёт к появлению ошибок, с которыми будет сложно бороться.componentWillUnmount()
. Этот метод знаменует собой окончание «жизни» компонента — тот момент, когда он удаляется из дерева DOM и исчезает с экрана.componentDidMount()
было настроено нечто вроде прослушивателя событий, благодаря которому, когда пользователь прокручивает страницу, выполняется некий код, именно в componentWillUnmount()
можно удалить такой прослушиватель событий. На самом же деле, у этого метода есть множество вариантов применения, которые направлены на то, чтобы убрать из приложения всё, что окажется ненужным после исчезновения компонента.App
, в который добавлены методы жизненного цикла:import React, {Component} from "react"
class App extends Component {
constructor() {
super()
this.state = {}
}
componentDidMount() {
// загрузить данные, необходимые для корректного отображения компонента
}
componentWillReceiveProps(nextProps) {
if (nextProps.whatever !== this.props.whatever) {
// сделать тут что-то важное
}
}
shouldComponentUpdate(nextProps, nextState) {
// вернуть true если компонент нуждается в обновлении
// вернуть false в противном случае
}
componentWillUnmount() {
// навести порядок после удаления компонента
// (например - убрать прослушиватели событий)
}
render() {
return (
<div>
Code goes here
</div>
)
}
}
export default App
componentWillMount()
, componentWillReceiveProps()
и componentWillUpdate()
. Также было сообщено о появлении двух новых методов. Это — статический метод getDerivedStateFromProps()
и метод getSnapshotBeforeUpdate()
. Нельзя сказать, что эти методы сыграют важную роль на будущих занятиях этого курса, но мы, несмотря на это, здесь с ними ознакомимся.getDerivedStateFromProps()
:static getDerivedStateFromProps(props, state) {
}
static
перед именем метода. Он, на основании принятых им свойств, должен возвратить обновлённое состояние. Он используется в тех случаях, когда некий компонент должен принимать входящие свойства, получаемые им от компонента-родителя, и настраивать своё состояние, основываясь на этих свойствах. Подробности об этом методе можно почитать здесь. В этом материале, опубликованном в блоге React, речь идёт о том, что применение этого метода оправдано далеко не во всех тех ситуациях, в которых он, как кажется, может пригодиться. Его неправильное использование может приводить к различным ошибкам, к падению производительности приложений, поэтому пользоваться им следует с осторожностью. Не следует пытаться решать с его помощью задачи, для решения которых он не предназначен. Вот документация к этому методу.getSnapshotBeforeUpdate()
. Вот как выглядит его объявление в теле класса:getSnapshotBeforeUpdate() {
}
componentDidMount()
. В следующий раз поговорим об условном рендеринге.К сожалению, не доступен сервер mySQL