Отслеживание ненужных повторных рендеров компонентов React с помощью библиотеки @welldone-software/why-did-you-render
Иногда вы знаете, что определенный компонент React не следует повторно отображать, если на это нет веской причины. Но как вы можете добиться этого?
На этом изображении мы видим, как библиотека уведомляет о ненужном обновлении BigListPureComponent.
Похоже, компоненту был передан всегда новый объект style:
И заставил весь список повторно визуализироваться при каждом рендеринге его отца (в данном случае, когда нажимается «увеличить»). Даже если другие реквизиты не менялись. Ни предметы, ни загрузка - нет.
›› ЗДЕСЬ ‹< - это песочница для тестирования.
В части 2 этой статьи мы расскажем о других случаях.
И даже хуже
Поскольку компонент является чистым, он постоянно сравнивает все свои свойства, чтобы решить, shouldComponentUpdate, а это тоже стоит дорого.
Но ... возвращаемое значение этого дорогостоящего расчета всегда верно, потому что: prevProps.style !== nextProps.style
Всегда. Ой…
Решение в этом случае
Создание объекта стиля должно переместиться из функций рендеринга, например, вот так:
const bigListStyle = {width: '100%'}
const Main = () => (
....
<BigListPureComponent style={bigListStyle} {...manyOtherProps}/>
)
Тогда он не будет повторно отображаться при повторном рендеринге Main.
Ой
Урок из этого примера заключается в том, что нам нужен способ гарантировать, что большие компоненты не будут повторно отрисовываться, когда они не должны этого делать.
Очевидно, это всего лишь простой пример. Иногда эти повторные рендеры вызываются гораздо более сложными сценариями, которые еще труднее заметить.
Помните: вы разрабатываете на очень мощном компьютере, поэтому вы, вероятно, не заметите проблем с производительностью при разработке. С другой стороны, ваши клиенты их не упустят. Если вы хотите, чтобы у ваших пользователей был лучший опыт, вы должны найти способ отслеживать и исправлять эти проблемы.
Почему вы сделали рендеринг
И вот мы подошли к библиотеке @welldone-software/why-did-you-render.
Запустив его при инициализации вашего приложения и добавив статический элемент whyDidYouRender к компонентам, которые вы хотите отслеживать, например:
class BigListPureComponent extends React.PureComponent {
static whyDidYouRender = true
// a lot of logic and handlers
render(){
return (
// a list of 1000000000000 entries
)
}
}
Если что-то пойдет не так, вы получите уведомление в консоли:
Если вы не хотите «загрязнять» свой код, вы также можете отслеживать компоненты по их имени, используя параметр include:
whyDidYouUpdate(React, {include: [/pure/]})
В этом примере мы отслеживаем все чистые компоненты из библиотеки перекомпоновать, которая меняет имя компонентов на pure(YourComponent).
Составление отчетов
Вы можете изменить способ сообщения о ненужных рендерах, чтобы сообщить о них объекту, удаленному журналу или записать их в файл.
Обеспечение соблюдения
Если вас беспокоит отсутствие этих журналов консоли, вы также можете использовать эту библиотеку в своих тестах. Библиотека отлично работает с ферментом и реактив-тест-рендерером, и, как упоминалось выше, вы можете сообщить объекту в своих тестах, чтобы убедиться, что ничего не было повторно отрисовано.
Chrome великолепен
Chrome позволяет сохранять объекты из консоли как глобальные объекты, чтобы вы могли легко получить к ним доступ из командной строки консоли:
Щелкните здесь, чтобы прочитать часть 2 этой статьи, где мы объясняем типичные сценарии исправления.
