Что такое render в react
Рендеринг элементов
Элементы — мельчайшие кирпичики React-приложений.
Элемент описывает то, что вы хотите увидеть на экране:
В отличие от DOM-элементов, элементы React — это простые объекты, не отнимающие много ресурсов. React DOM обновляет DOM, чтобы он соответствовал переданным React-элементам.
Элементы можно перепутать с более известной концепцией «компонентов». С компонентами мы ознакомимся в следующей главе. Элементы — это то, «из чего сделаны» компоненты, и мы рекомендуем вам дочитать эту главу, прежде чем двигаться дальше.
Рендеринг элемента в DOM
Допустим, в вашем HTML-файле есть
Мы назовём его «корневым» узлом DOM, так как React DOM будет управлять его содержимым.
Обычно в приложениях, написанных полностью на React, есть только один корневой элемент. При встраивании React в существующее приложение вы можете рендерить во столько независимых корневых элементов, во сколько посчитаете нужным.
Для рендеринга React-элемента в корневой узел DOM вызовите ReactDOM.render() с React-элементом и корневым DOM-узлом в качестве аргументов:
На странице будет написано «Hello, world».
Обновление элементов на странице
Элементы React иммутабельны. После создания элемента нельзя изменить его потомков или атрибуты. Элемент похож на кадр в фильме: он отражает состояние интерфейса в конкретный момент времени.
Рассмотрим пример с часами:
На практике большинство React-приложений вызывают ReactDOM.render() только один раз. В следующем разделе вы узнаете, как можно обновлять интерфейс при помощи компонента с состоянием.
Мы рекомендуем не пропускать главы, поскольку каждая следующая глава опирается на знания из предыдущей.
React обновляет только то, что необходимо
React DOM сравнивает элемент и его дочернее дерево с предыдущей версией и вносит в DOM только минимально необходимые изменения.
Вы можете убедиться в этом на последнем примере с помощью инструментов разработки в браузере:
Несмотря на то, что мы создаём элемент, описывающий всё UI-дерево, каждую секунду React DOM изменяет только текстовый узел, содержимое которого изменилось.
Проще описать, как интерфейс выглядит в конкретный момент, чем как он изменяется с течением времени. По нашему опыту, такой подход позволяет избавиться от целого класса ошибок.
Отрисовка элементов
Элементы — это самые маленькие строительные блоки приложений React.
Элемент описывает, что вы хотите видеть на экране:
Unlike browser DOM elements, React elements are plain objects, and are cheap to create. React DOM takes care of updating the DOM to match the React elements.
В отличие от DOM-элементов браузера, элементы React — обычные объекты, лёгкие для создания. React DOM берёт заботу по обновлению DOM на себя для соответствия элементам React.
Может сбить с толку элементы с более широко известной концепцией «компонентов». Мы представим компоненты в следующем разделе (/docs/components-and-props.html). Элементы — это то, что из чего компоненты «сделаны», и мы рекомендуем вам прочитать этот раздел, прежде чем идти вперёд.
Отрисовка элемента в DOM
Предположим, что в вашем файле HTML есть
Мы называем это «корневым» узлом DOM, потому что всё внутри него будет управляться DOM React.
У приложений, созданных только с использованием React, обычно есть только единственный корневой узел DOM. Если вы интегрируете React в существующее приложение, у вас может быть как можно больше изолированных корневых узлов DOM.
Чтобы отрисовать элемент React в корневом узле DOM, передайте его в ReactDOM.render() :
На странице отобразится «Привет, мир».
Обновление отрисованного элемента
React-элементы — неизменяемы. Создав однажды элемент, вы не сможете изменить его дочерние элементы или атрибуты. Элемент похож на один кадр в фильме: он представляет собой пользовательский интерфейс в определённый момент времени.
Рассмотрим этот пример тикающих часов:
Мы рекомендуем вам не пропускать эти темы, потому что они опираются друг на друга.
React обновляет только то, что необходимо
DOM React сравнивает элемент и его дочерние элементы с предыдущими и применяет только обновления DOM, необходимые для преобразования DOM в желаемое состояние.
Вы можете убедиться в том, проверив последний пример с помощью инструментов браузера:
Несмотря на то, что мы создаём элемент, описывающий всё дерево пользовательского интерфейса на каждом тике, только текстовый узел, содержимое которого изменилось, обновляется в DOM React.
По нашему опыту, размышление о том, как пользовательский интерфейс должен выглядеть в любой данный момент, а не то, как его менять со временем, устраняет целый класс багов.
Render Props
The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.
A component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.
Libraries that use render props include React Router, Downshift and Formik.
In this document, we’ll discuss why render props are useful, and how to write your own.
Use Render Props for Cross-Cutting Concerns
Components are the primary unit of code reuse in React, but it’s not always obvious how to share the state or behavior that one component encapsulates to other components that need that same state.
For example, the following component tracks the mouse position in a web app:
As the cursor moves around the screen, the component displays its (x, y) coordinates in a
Now the question is: How can we reuse this behavior in another component? In other words, if another component needs to know about the cursor position, can we encapsulate that behavior so that we can easily share it with that component?
Since components are the basic unit of code reuse in React, let’s try refactoring the code a bit to use a component that encapsulates the behavior we need to reuse elsewhere.
Now the component encapsulates all behavior associated with listening for mousemove events and storing the (x, y) position of the cursor, but it’s not yet truly reusable.
For example, let’s say we have a component that renders the image of a cat chasing the mouse around the screen. We might use a prop to tell the component the coordinates of the mouse so it knows where to position the image on the screen.
As a first pass, you might try rendering the inside ’s render method, like this:
This approach will work for our specific use case, but we haven’t achieved the objective of truly encapsulating the behavior in a reusable way. Now, every time we want the mouse position for a different use case, we have to create a new component (i.e. essentially another ) that renders something specifically for that use case.
Here’s where the render prop comes in: Instead of hard-coding a inside a component, and effectively changing its rendered output, we can provide with a function prop that it uses to dynamically determine what to render–a render prop.
Now, instead of effectively cloning the component and hard-coding something else in its render method to solve for a specific use case, we provide a render prop that can use to dynamically determine what it renders.
More concretely, a render prop is a function prop that a component uses to know what to render.
This technique makes the behavior that we need to share extremely portable. To get that behavior, render a with a render prop that tells it what to render with the current (x, y) of the cursor.
One interesting thing to note about render props is that you can implement most higher-order components (HOC) using a regular component with a render prop. For example, if you would prefer to have a withMouse HOC instead of a component, you could easily create one using a regular with a render prop:
So using a render prop makes it possible to use either pattern.
Using Props Other Than render
It’s important to remember that just because the pattern is called “render props” you don’t have to use a prop named render to use this pattern. In fact, any prop that is a function that a component uses to know what to render is technically a “render prop”.
And remember, the children prop doesn’t actually need to be named in the list of “attributes” in your JSX element. Instead, you can put it directly inside the element!
You’ll see this technique used in the react-motion API.
Since this technique is a little unusual, you’ll probably want to explicitly state that children should be a function in your propTypes when designing an API like this.
Be careful when using Render Props with React.PureComponent
Using a render prop can negate the advantage that comes from using React.PureComponent if you create the function inside a render method. This is because the shallow prop comparison will always return false for new props, and each render in this case will generate a new value for the render prop.
In this example, each time renders, it generates a new function as the value of the prop, thus negating the effect of extending React.PureComponent in the first place!
To get around this problem, you can sometimes define the prop as an instance method, like so:
React.Component
Эта страница содержит подробный справочник API для определения классового компонента React. Предполагается, что вы знакомы с такими концепциями React, как компоненты и пропсы, а также состояние и жизненный цикл. Прочитайте про них, если вы этого не сделали.
React позволяет определять компоненты как классы или функции. В настоящее время классовые компоненты имеют больше возможностей. Они разобраны на этой странице. Чтобы определить такой компонент, необходимо отнаследоваться от React.Component :
Мы рекомендуем не создавать собственные классы базовых компонентов. В компонентах React повторное использование кода обычно достигается за счёт композиции, а не наследования.
React не заставляет вас использовать синтаксис классов из ES6. Вместо этого вы можете использовать модуль create-react-class или его аналоги. Посмотрите раздел Использование React без ES6, чтобы узнать больше.
Жизненный цикл компонента
Каждый компонент имеет несколько «методов жизненного цикла». Переопределение такого метода позволяет выполнять код на конкретном этапе этого процесса. Вы можете использовать эту диаграмму жизненного цикла как шпаргалку. Далее на странице полужирным шрифтом выделены самые распространённые методы жизненного цикла.
При создании экземпляра компонента и его вставке в DOM, следующие методы вызываются в установленном порядке:
Этот метод устарел. Не используйте его в новом коде.
Обновление происходит при изменении пропсов или состояния. Следующие методы вызываются в установленном порядке при повторном рендере компонента:
Эти методы устарели. Не используйте их в новом коде.
Этот метод вызывается при удалении компонента из DOM:
Следующие методы вызываются, если произошла ошибка в процессе рендеринга, методе жизненного цикла или конструкторе любого дочернего компонента.
В каждом компоненте доступны методы API:
Распространённые методы жизненного цикла
Методы в этом разделе охватывают большинство задач, с которыми вы столкнётесь при использовании React-компонентов. Для визуального представления вы можете использовать эту диаграмму жизненного цикла.
render() — единственный обязательный метод в классовом компоненте.
При вызове он проверяет this.props и this.state и возвращает один из следующих вариантов:
Функция render() должна быть чистой. Это означает, что она не изменяет состояние компонента, всегда возвращает один и тот же результат, не взаимодействует напрямую с браузером.
Взаимодействовать с браузером необходимо в componentDidMount() или других методах жизненного цикла. Чистый render() делает компонент понятным.
Вы можете не использовать конструктор в React-компоненте, если вы не определяете состояние или не привязываете методы.
Конструкторы в React обычно используют для двух целей:
Не копируйте пропсы в состояние! Это распространённая ошибка:
Прочитайте нашу статью в блоге про отсутствие необходимости в производном состоянии. Она описывает случаи, в которых вам необходимо состояние, зависящее от пропсов.
componentDidMount() вызывается сразу после монтирования (то есть, вставки компонента в DOM). В этом методе должны происходить действия, которые требуют наличия DOM-узлов. Это хорошее место для создания сетевых запросов.
componentDidUpdate() вызывается сразу после обновления. Не вызывается при первом рендере.
Метод позволяет работать с DOM при обновлении компонента. Также он подходит для выполнения таких сетевых запросов, которые выполняются на основании результата сравнения текущих пропсов с предыдущими. Если пропсы не изменились, новый запрос может и не требоваться.
Редко используемые методы жизненного цикла
Методы из этого раздела используются редко. В большинстве компонентов они не нужны, хотя иногда бывают полезны. Вы можете увидеть большинство приведённых ниже методов на этой диаграмме жизненного цикла, если наверху страницы нажмёте на чекбокс «Показать менее популярные методы жизненного цикла».
Этот метод нужен только для повышения производительности. Но не опирайтесь на его возможность «предотвратить» рендер, это может привести к багам. Вместо этого используйте PureComponent , который позволяет не описывать поведение shouldComponentUpdate() вручную. PureComponent поверхностно сравнивает пропсы и состояние и позволяет не пропустить необходимое обновление.
Этот метод существует для редких случаев, когда состояние зависит от изменений в пропсах. Например, это подойдёт для реализации компонента
Производное состояние приводит к сложному коду и делает ваши компоненты сложными для понимания. Убедитесь, что вы знакомы с простыми альтернативами:
Если вы хотите повторно использовать код между getDerivedStateFromProps() и другими методами класса, извлеките чистые функции пропсов и состояния компонента и поместите их вне определения класса.
Это применяется редко, но может быть полезно в таких интерфейсах, как цепочка сообщений в чатах, в которых позиция прокрутки обрабатывается особым образом.
Значение снимка (или null ) должно быть возвращено.
В примерах выше важно получить значение свойства scrollHeight в getSnapshotBeforeUpdate из-за того, что могут возникать задержки между этапами жизненного цикла «рендер» (например, render ) и «фиксирование» (например, getSnapshotBeforeUpdate и componentDidUpdate ).
Предохранители — это React-компоненты, которые перехватывают JavaScript-ошибки в любом месте их дочернего дерева компонентов. Затем логируют эти ошибки и отображают запасной интерфейс вместо «поломанного» дерева компонентов. Предохранители отлавливают ошибки при рендере, в методах жизненного цикла и в конструкторах всего дерева под ними.
Используйте предохранители только для обработки неожиданных исключений, не используйте их для управления потоком исполнения в вашем приложении.
Предохранители перехватывают ошибки в компонентах ниже по дереву. Предохранители не могут поймать ошибку внутри себя.
Этот метод жизненного цикла вызывается после возникновения ошибки у компонента-потомка. Он получает ошибку в качестве параметра и возвращает значение для обновления состояния.
Этот метод жизненного цикла вызывается после возникновения ошибки у компонента-потомка. Он получает два параметра:
componentDidCatch() вызывается во время этапа «фиксации», поэтому здесь можно использовать побочные эффекты. Метод можно использовать для логирования ошибок.
Обработка ошибок в методе componentDidCatch() отличается между React-сборками для продакшена и разработки.
Устаревшие методы жизненного цикла
Приведённые ниже методы жизненного цикла устарели. Их не рекомендуется использовать в новом коде, хотя они продолжают работать. Вы можете узнать больше о переходе с устаревших методов жизненного цикла в блоге.
Это единственный метод жизненного цикла, вызываемый при серверном рендеринге.
Использование этого метода жизненного цикла часто приводило к багам
Обратите внимание, если родительский компонент заставляет ваш компонент повторно рендериться, метод будет вызываться, даже если пропсы не изменились. Убедитесь, что сравниваете текущие и следующие значения, если вы хотите обрабатывать изменения.
UNSAFE_componentWillUpdate() вызывается непосредственно перед рендером при получении новых пропсов или состояния. В этом методе можно выполнить некоторую подготовку перед обновлением. Этот метод не вызывается при первом рендере.
В отличие от методов жизненного цикла, представленных выше (React вызывает их сам), методы, приведённые ниже, можно вызывать из компонентов.
setState() добавляет в очередь изменения в состоянии компонента. Также он указывает React, что компонент и его дочерние элементы должны быть повторно отрендерены с обновлённым состоянием. Этот метод используется для обновления интерфейса в ответ на обработчики событий и ответы сервера.
Эта форма записи setState() также асинхронна, и несколько вызовов в течение одного цикла могут быть объединены вместе. Например, вам нужно увеличить количество элементов несколько раз в одном цикле. Результат этого можно представить так:
Последующие вызовы будут переопределять значения из предыдущих вызовов того же цикла. Из-за этого количество увеличится только один раз. В случае, если следующее состояние зависит от текущего, мы рекомендуем использовать форму функции обновления:
Для более подробной информации смотрите:
Если props.color не передаётся, по умолчанию установится ‘синий’ :
Строка displayName используется в сообщениях для отладки. Обычно вам не нужно её явно указывать. По умолчанию используется имя функции или класса, указанное при определении компонента. Если вам нужно установить его явно, например, для отладки или создания компонента высшего порядка, посмотрите раздел Обёртка отображаемого имени для простой отладки.
this.props содержит свойства, которые были определены тем, кто вызывает этот компонент. Подробнее об этом можно узнать в разделе Компоненты и пропсы
Состояние содержит данные, специфичные для этого компонента. Они могут измениться со временем. Состояние определяется пользователем и должно быть простым объектом JavaScript.
Вам не нужно вставлять в состояние значение, если оно не используется для рендера или потока данных (например, идентификатор таймера). Такие значения можно определить как поля экземпляра компонента.
Дополнительную информацию можно найти в разделе Состояние и жизненный цикл.
Руководство по рендеренгу в React
Render не перерисовывает DOM дерево, его задача — формирование «виртуального» дерева. Если полученное дерево совпадает с предыдущим, то обновления DOM не произойдет.
Процесс обновления UI в React приложении состоит из трех фаз:
Render — формирование текущего дерева компонентов на основании их свойств (props) и состояния (state)
Reconciliation — сравнение и вычисление отличий с предыдущим деревом
Commit — обновление DOM
После первичного рендеринга и отображения приложения в DOM дереве, повторный рендер может быть вызван по одной из следующих причин.
Для классовых компонентов:
Для функциональных компонентов:
Рендер дочерних компонентов
По умолчанию, если рендерится родительский компонент, то все его дочерние компоненты будут перерендерены, даже если их props не изменились.
Рендер «дешевая» операция, по сравнению с обновлением DOM дерева. Если, выполняя рендер, React увидит, что текущий результат рендера совпадает с предыдущим, то обновление DOM не произойдет (фаза commit будет пропущена). Но процесс рендеринга и сравнения (фазы render и reconciliation) тоже занимают некоторое время, и в ряде случаев можно пропустить их для оптимизации производительности.
Оптимизация рендеринга заключается в том, чтобы не делать его без необходимости.
Для предотвращения лишнего рендера могут быть использованы:
Используйте React.memo() на родительском компоненте, чтобы остановить каскадный рендер всех дочерних компонентов.
Мемоизация тоже имеет свою цену и применять ее следует при необходимости. По этой причине, стандартно, React компоненты не мемоизированы.
Стандартные методы оптимизации сравниваются объекты и функции в props как ссылки, и если ссылка меняется, то произойдет рендер, даже если новый объект эквивалентен предыдущему:
, функция onClick будет создаваться заново. Для того, чтобы это предотвратить, нужно использовать специальные методы, которые сохраняют ссылки на неизменные объекты между рендерами.
Данная особенность касается функциональных компонентов, так как экземпляр классового компонента и ссылки на его методы находятся в памяти и не меняются.
Избегайте случайной инициализации объекта или функции непосредственно в props, это является распространенной ошибкой:
Чтобы в функциональном компоненте сохранить ссылки на объекты между рендерами, используйте хуки:
Хуки useMemo() и useCallback() принимают вторым аргументом массив зависимостей. Изменение зависимостей приведет к перерасчету значения, которое возвращает хук.
Не производите замер производительности в develop режиме, только в production сборке.
Полезные статьи по профилированию производительности:
React’s Context API обеспечивает передачу переменных в дерево компонентов, без их непосредственной передачи в props данных компонентов.
Context не является стейт-менеджером. Вы должны сами управлять значениями, которые передаются в Контекст. Обычно это достигается созданием компонента со стейтом, который устанавливает из него переменные Контекста.
Для функциональных компонентов хук:
Если значение Контекст обновлено, то все компоненты, которые его используют, будут перерендерены. Нет способа это изменить.
Если в Контекст передан массив, или объект, то при его изменении, будут перерендерен каждый компонент, использующий данный Контекст. Даже если изменилась только часть объекта, которую непосредственно этот компонент не использует.
Следует помнить, что рендер родительского компонента, вызывает рендер всех его дочерних компонентов, по этому:
Компонент, который находится под Context Provider, почти гарантированно должен использовать React.memo.
Далее рассмотрим сценарий обновления компонентов, использующих мемоизацию и Контекст.
Контекст и мемоизация
Если выполнить setA(42) произойдет следующее:
React-Redux и Context
Redux и Контекст — разные инструменты и делают разную работу.
Несмотря на то, что Redux использует Контекст, имеются существенные отличия. Redux передает в Контекст экземпляр хранилища, ссылка на экземпляр всегда неизменна. Таким образом, React не обновляет компоненты при изменении значений в хранилище стандартным способом. Логикой обновления компонентов занимается непосредственно модуль, связывающий React и Redux.
Контекст, при изменении значения в провайдере, вызывает рендер для каждого компонента. Redux вызывает рендер только для тех компонентов, которые непосредственно используют измененные значения. Но при использовании Redux, для каждого компонента запускается селектор и сравниваются значения.
Обычно реализация в Redux (запуск селекторов, сравнение старого и нового значения, рендеринг если значение изменилось) работает быстрее, чем стандартная реализация на Контексте (полный перерендер дерева). Но при наличии сложных вычислений в селекторах, или если селекторы случайно возвращают новую ссылку, возможна потеря производительности.
Connect и useSelector
Свойства, которые передаются HOC’ом в компонент, формируются по такому принципу:
Хук useSelector() запускается внутри функционального компонента и не имеет возможности остановить рендер данного компонента, если рендерится его родительский компонент.