Inline-пропсы в React тихо обнуляют memo: разбор на 200 строк, как чинить
Перевод материала LogRocket: контролируемый эксперимент с 200 memoized React-строк показывает, как inline-объекты и колбэки в JSX обнуляют React.memo и превращают одно нажатие клавиши в коммит 243,9 мс. Простой рефактор возвращает время до 6 мс. Разбор с кодом и метриками профайлера.
Совет по производительности React обычно сводится к набору рецептов: оборачиваем дорогие дочерние компоненты в React.memo, добавляем useCallback к обработчикам, useMemo к вычислениям — и идём дальше. На практике эти инструменты работают только тогда, когда передаваемые через них значения действительно стабильны. Если родитель пересоздаёт объект или функцию на каждом рендере, React видит новую ссылку и memoization-граница перестаёт делать полезную работу.
В материале на блоге LogRocket разобран один из самых частых React-паттернов, который в неподходящем контексте оказывается одним из самых дорогих, — передача inline-объектов, массивов и колбэков прямо в месте вызова компонента. Контролируемый эксперимент с 200 memoized строк показывает, как это превращает один keystroke в коммит на 243,9 мс — и как простой рефактор возвращает время до 6 мс.
Главное
Ключевые выводы
React.memo сравнивает по ссылке. Внутри React работает Object.is: {padding:16} и {padding:16} — это разные ссылки, значит «изменилось».
Inline-объекты в JSX обнуляют memo. Каждый рендер родителя создаёт новый объект/функцию, мемоизированный дочерний компонент видит «новые пропсы» и перерисовывается заново. Оптимизация, которую вы планировали, не срабатывает.
Цена в живом коде. Эксперимент: 200 memoized строк, поиск, inline style и onAddToCart. После 6 нажатий — счётчик рендеров каждой строки = 14, на keystroke коммит 243,9 мс.
Фикс простой. Статичный объект — в module scope. Динамический колбэк — в useCallback с пустыми зависимостями. После: коммит 6 мс, счётчик рендеров = 2, Why Did You Render молчит.
React Compiler не отменяет понимания. Он автоматизирует много memoization, но useMemo/useCallback остаются escape hatch для случаев, когда нужен точный контроль (например, dependency для Effect).
Как работает bailout у React
React.memo оборачивает компонент в memoization-границу. Когда родитель ререндерится, React не пропускает дочерний автоматически только потому, что он мемоизирован. Вместо этого сравниваются новые пропсы со старыми. Если каждый пропс считается равным — bail out, переиспользуем предыдущий результат. Если хотя бы один не равен — рендер. По умолчанию React сравнивает попропсово через Object.is.
Эта деталь критична, потому что для объектов и функций Object.is — это, по сути, проверка по ссылке:
Содержимое выглядит идентичным, но ссылки разные. React поэтому считает их изменёнными. Именно по этой причине inline-объекты и колбэки оказываются скрытой причиной того, что мемоизированный дочерний компонент продолжает ререндериться.
Та же логика объясняет, зачем нужны useCallback и useMemo. По документации React, useCallback кеширует определение функции между рендерами, а useMemo — результат вычисления. Оба помогают только тогда, когда зависимости остаются достаточно стабильными, чтобы React переиспользовал предыдущее значение. Если положить в массив зависимостей нестабильный объект, React видит новую зависимость на каждом рендере и пересчитывает заново.
Это и объясняет, почему баг ощущается запутанным в реальном приложении. Значения «выглядят» неизменными для человека: у style-объекта те же ключи, тело колбэка идентично, config всё ещё говорит то же самое. Но React не сравнивает намерение или структуру — он сравнивает идентичность.
Когда inline-пропсы реально становятся проблемой
Стоит провести границу между теоретической и практической ценой. Inline-колбэк сам по себе — не баг производительности. Если ребёнок дешёвый, частота рендера низкая и memoization-границы вокруг нет, измеримого отрицательного эффекта может вообще не быть. И в документации React, и в гайдах LogRocket по производительности — общее место: оптимизация работает там, где есть реальные узкие места, а не гипотетические.
Проблема начинается, когда сходятся три условия одновременно:
- Родитель ререндерится часто (поиск, скролл, фильтры, анимация, live data).
- Дочерний компонент или поддерево большое — лишняя работа заметна.
- Вы уже добавили memoization и ждёте, что React пропустит работу, когда «ничего важного не изменилось».
В такой связке нестабильные inline-ссылки не просто добавляют немного оверхеда — они обнуляют ту оптимизацию, которую вы намеренно ввели. И этот паттерн коварен в продакшене: он не объявляет себя багом. UI работает, исключений нет, предупреждений нет, и без профилировщика часто нет очевидного запаха. Цена проявляется иначе: тормозящая фильтрация списков, лаг ввода, шумные flame-графы и компонентные деревья, которые продолжают перерисовываться, даже когда осмысленные данные не менялись.
Контролируемый эксперимент: 200 memoized строк
Чтобы не спорить «плохо или нормально», автор поста собрал контролируемый тест: поисковый список товаров с 200 memoized строками, где каждая строка получает одинаковые логические значения, но новые ссылки на объект и функцию на каждом рендере родителя. Это позволяет напрямую увидеть, делает ли React.memo bail out или всё поддерево ререндерится на каждое нажатие клавиши.
Представьте storefront UI с 200 memoized ProductRow. Родитель — ProductList — хранит searchTerm в state. Каждое нажатие апдейтит state, ререндерит ProductList и снова прогоняет JSX, который мапает отфильтрованные товары. В эксперименте каждая ProductRow обёрнута в memo и помечена whyDidYouRender = true, но получает два inline-пропса в месте вызова:
Это ровно тот случай, о котором React предупреждает при передаче функций в memoized-компоненты: свежая функция или объект, созданные во время рендера, не пройдут сравнение пропсов, если ссылку не стабилизировать.
В эксперименте эффект становится виден почти мгновенно. Объект style и колбэк onAddToCart пересоздаются каждый раз, когда ререндерится ProductList, поэтому memo-обёртка видит изменённые пропсы для каждой строки на каждом нажатии. Счётчик рендеров делает это конкретным: после шести нажатий каждая видимая строка показывает Renders: 14. React Profiler затем показывает рантайм-цену ошибки: одно нажатие порождает коммит, в котором ProductList занимает 243,9 мс и все 200 row-fibers светятся в flame-графе.
Здесь React Developer Tools отрабатывают по полной. По официальной документации, React DevTools позволяют инспектировать компоненты, редактировать пропсы и state, а также находить проблемы производительности. Профайлер также доступен программно через <Profiler>, но интерактивный вид DevTools обычно используется командами для отладки.
Why Did You Render делает корневую причину ещё нагляднее. Пакет модифицирует React и сообщает о потенциально избегаемых ререндерах. В этом примере он рапортует props.style как «different objects that are equal by value» и props.onAddToCart как «different functions with the same name» — ровно тот референциальный мисматч, который мы и ожидаем. Это диагностический инструмент только для разработки, не для прода, но крайне эффективный для выявления этого класса багов.
Рефакторинг, который реально решает проблему
Чтобы остановить каскад рендеров, нужны стабильные ссылки. Концептуально фикс прост: значения, которые не меняются, не должны пересоздаваться во время рендера; колбэки, которым нужно жить через рендеры, должны быть memoized, когда ребёнок зависит от референциальной стабильности.
Вынос ROW_STYLE в module scope решает проблему на самом дешёвом уровне: React никогда не видит новую ссылку на объект, потому что он создаётся один раз вне компонента. Использование useCallback для handleAddToCart даёт ребёнку стабильную ссылку на функцию между рендерами, пока массив зависимостей не меняется. Это и есть тот случай, для которого React документирует useCallback при передаче функций в мемоизированных детей.
В эксперименте стабилизация ссылок восстанавливает bail-out. Измеренный результат впечатляет: ProductList падает с 243,9 мс до 6 мс, бейджи рендеров остаются на 2 сколько ни печатай, и Why Did You Render замолкает — избегаемых референциальных мисматчей больше нет.
Когда стабилизировать ссылки, а когда — нет
Это часть, которая часто теряется в дискуссиях про производительность. Урок не «никогда не используй inline-объекты» и не «оборачивай всё в useCallback». Урок: memoization — это контракт. Если ребёнок полагается на референциальное равенство, чтобы пропустить работу, родитель обязан этот контракт уважать и передавать стабильные ссылки.
Но это не значит, что каждому компоненту нужна агрессивная мемоизация. Современные рекомендации React всё ещё трактуют memoization как точечную оптимизацию, а не дефолтный стиль. Если рендер дешёвый, поддерево маленькое или ребёнок не memoized, стабилизация ссылок может добавить сложности без реальной выгоды. Поэтому большинство гайдов по React performance, включая обзоры LogRocket, акцентируют профилировку прежде, чем механически оптимизировать.
Полезное правило большого пальца: сначала перенеси, потом мемоизируй. Если значение статично — вынеси его за пределы тела компонента, прежде чем тянуться к хукам. Это даёт референциальную стабильность почти без когнитивной или рантайм-нагрузки. useCallback и useMemo — только когда значение реально динамическое и ребёнок выигрывает от стабильной идентичности.
Меняет ли это React Compiler
Один актуальный нюанс — React Compiler. Документация описывает его как стабильный билд-тайм инструмент, который автоматически оптимизирует React-приложения и по умолчанию мемоизирует код на основе анализа и эвристик. Это уменьшает потребность в ручных useMemo, useCallback и React.memo, особенно в новом коде.
Но это не делает референциальную стабильность нерелевантной. Документация также отмечает, что useMemo и useCallback остаются полезными как escape hatch для случаев, когда разработчику нужен точный контроль — например, чтобы держать memoized-значение стабильным как зависимость для Effect. Так что даже в кодовых базах, переходящих на React Compiler, всё равно полезно понимать, как нестабильные ссылки влияют на ререндеры, результаты профайлера и кейсы, где ручной контроль ещё нужен.
Часто задаваемые вопросы
Стоит ли вообще писать inline-объекты в JSX?
Да, в большинстве случаев это нормальный JavaScript внутри JSX. Проблемой это становится только тогда, когда они пересекают memoization-границу и вы ожидаете, что React воспримет «то же значение» как «тот же пропс». Если ребёнок не memoized, рендер дешёвый и поддерево маленькое — никаких изменений в коде не нужно.
Как понять, что баг реально из-за нестабильных ссылок?
Профайлите. Откройте React DevTools Profiler, запустите запись, выполните взаимодействие (нажатие, поиск, скролл) и посмотрите flame-граф. Если memoized поддерево всё равно полностью перерисовывается, проверьте пропсы. Why Did You Render быстро покажет, какие именно пропсы изменились между рендерами. Сообщения вида «different objects that are equal by value» или «different functions with the same name» — прямой сигнал, что виноваты inline-ссылки.
Когда useCallback избыточен?
Когда колбэк передаётся в не-memoized компонент или в DOM-элемент, который не сравнивает props по ссылке. В таких случаях стабилизация не даёт выгоды, но добавляет шум в код и потенциальные баги в массиве зависимостей. Используйте useCallback только когда у получающего компонента есть memoization-граница и стабильная идентичность реально нужна.
Если перейти на React Compiler — фикс уже не нужен?
Скорее всего, не нужен в большинстве рутинных случаев — компилятор автоматически мемоизирует то, что считает стоящим. Но он не отменяет понимания референций. Эффекты с нестабильными зависимостями, точная стабилизация для сторонних библиотек, кросс-компонентные кейсы — всё это по-прежнему может требовать ручных useMemo/useCallback. И профилировать всё равно надо: компилятор не панацея.
Итог
Inline-объекты и inline-колбэки — не плохой React-код по умолчанию. Чаще всего это просто обычные JavaScript-выражения внутри JSX. Проблема появляется, когда они пересекают memoization-границу и вы ждёте, что React воспримет «то же значение» как «тот же пропс». По умолчанию React сравнивает пропсы и зависимости хуков через Object.is, поэтому для объектов и функций новой ссылки достаточно, чтобы React счёл значение изменившимся.
Этот паттерн заслуживает большего внимания, чем обычно получает. Это не пустяковая микрооптимизация. Это один из самых простых способов случайно обнулить React.memo — особенно в фильтруемых списках, дашбордах, search-heavy UI и компонентных деревьях с дорогими потомками. Код выглядит чистым, приложение работает, но оптимизация, на которую вы рассчитывали, исчезает.
Практический вывод для команд, строящих быстрые React-интерфейсы: профилируй сначала. Если memoized поддерево всё ещё ререндерится слишком часто — проверь пропсы прежде, чем винить React. Перенеси статичные объекты из render-пути. Мемоизируйте колбэки только тогда, когда ребёнок реально выигрывает. Используй React DevTools и Why Did You Render, чтобы подтвердить, что именно изменилось и почему. Делай это последовательно — и React.memo перестанет быть декоративным куском кода и начнёт делать свою работу.
Источник: The React pattern everyone uses that quietly kills performance — LogRocket Blog.
