Браузер и фронтенд-рантайм
React fiber: тест с выбором ответа
Суть Синтез всего модуля fiber в формате вопросов с выбором — render vs commit, дерево с двойной буферизацией, ключи реконсиляции, lanes и time-slicing, bailout и tearing.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь модуль. Ни один из них — не определение для заучивания: каждый отражает решение, которое вы принимаете в реальном инциденте производительности, где render-фаза, commit-фаза, ключи, lanes и bailout взаимодействуют между собой.
Цель
Убедитесь, что умеете связать две фазы реконсилера, двойную буферизацию fiber, идентичность при reconciliation, планировщик lanes и механизм bailout — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Компонент инкрементирует счётчик уровня модуля прямо в теле функции. В React 17 это работало; в React 18 StrictMode счётчик вдвое больше ожидаемого, а в продакшене под нагрузкой иногда утраивается. В чём корневая причина?
Heads-up Реконсилер React работает в единственном главном потоке — второго потока, участвующего в гонке, нет. Недетерминизм происходит из переигрываемости render-фазы, а не из конкурентности между потоками.
Heads-up StrictMode работает только в разработке и намеренно вызывает компонент дважды, чтобы вскрыть нечистый рендер. Удаление скрывает симптом; нечистый побочный эффект всё равно неверен при concurrent rendering в продакшене.
Heads-up useState не исправит побочный эффект, срабатывающий во время рендера; исправление — вообще перестать выполнять эффект в теле функции. Render должна быть чистой независимо от того, где хранится значение.
Викторина
Completed
Рендер идёт уже 30 мс, когда приходит более приоритетное нажатие клавиши. React отбрасывает незавершённое дерево workInProgress и начинает заново. Почему отбрасывание полупостроенного дерева ничего не стоит визуально?
Heads-up Никакой транзакции отката нет. Стоимость нулевая, потому что ничего не было применено — DOM трогает commit, а не render, и commit не начинался.
Heads-up Указатель alternate связывает каждый fiber с его близнецом для дешёвого клонирования и bailout — это не журнал отмены. Отменять нечего, потому что render-фаза не производит изменений DOM.
Heads-up Пользователь никогда не видит workInProgress. Рисуется только current-дерево, и оно остаётся согласованным, потому что отброшенное дерево живёт исключительно в памяти.
Викторина
Completed
Список рендерится с key={index}. Чекбокс, отмеченный в третьей строке, остаётся отмеченным на неправильной строке после удаления первой строки, но текстовые подписи при этом все корректны. Чем объясняется такое расщепление поведения?
Heads-up Состояние не было потеряно — оно сохранилось на неправильном fiber. Fiber остались на местах; сместились только данные, с которыми они спарены, потому что индексные ключи позиционны.
Heads-up Порядок commit корректен и детерминирован. Рассогласование произошло раньше, в reconciliation, где индексные ключи заставили React спарить fiber с неправильными элементами.
Heads-up Со стабильными ключами-идентичностями чекбокс корректно отслеживает свой элемент при удалениях. Баг специфичен для индекса-как-ключа, а не общее свойство чекбоксов.
Викторина
Completed
Поле поиска фильтрует список из 5 000 строк. Ввод дёргается. Вы оборачиваете setState отфильтрованного списка в startTransition. Ввод теперь мгновенный — но почему сам список не замораживает страницу, когда наконец рендерится?
Heads-up Фонового потока нет — React рендерит в главном потоке. startTransition понижает приоритет обновления, делая его прерываемым и разбитым time-slicing, а не распараллеленным.
Heads-up startTransition не делает debounce; фильтр всё равно выполняется. Он меняет приоритетную lane обновления, чтобы рендер уступал срочному вводу, а не уменьшает частоту срабатываний.
Heads-up Time-slicing применяется к render-фазе, а не к commit. Commit всегда атомарна и непрерываема; прерываемой startTransition делает именно работу рендера, а не commit.
Викторина
Completed
Дочерний компонент, обёрнутый в React.memo, перерендеривается при каждом рендере родителя. Причина в Profiler — 'props changed', но содержимое пропа каждый раз идентично. Что происходит?
Heads-up Сравнение по умолчанию в React.memo — поверхностное Object.is по каждому пропу, не глубокое. Он сообщает о реальном различии ссылок: проп — новый объект каждый рендер, хотя содержимое совпадает.
Heads-up Хуки не отключают memo. memo решает, произойдёт ли вообще вход в render-фазу; как только рендер пошёл, хуки компонента выполняются обычным образом. Срыв вызван нестабильной ссылкой пропа.
Heads-up React.memo активен в разработке. Перерендер реален и вызван неравенством ссылок пропа, а не отключением memo.
Викторина
Completed
Дашборд управляется внешним стором. После включения concurrent-фич вы иногда видите, что хедер показывает одну сумму, а соседняя панель — другую сумму в том же кадре. Какой механизм виноват и что это исправляет?
Heads-up Устаревшее замыкание даёт стабильно старое значение, а не два разных значения в одном кадре. Признак tearing — внутренняя несогласованность в пределах одного commit, вызванная мутацией стора между слайсами рендера.
Heads-up useMemo кэширует вычисленное значение внутри одного компонента; он ничего не делает с внешним стором, меняющимся в середине рендера по всему дереву. Безопасная для конкурентности точка интеграции — useSyncExternalStore.
Heads-up Внутреннее состояние React не может tearing, потому что React контролирует точный момент его изменения. Tearing возникает только с внешними сторами, которые React не контролирует — именно для этого и существует useSyncExternalStore.
Итог
Сквозная линия модуля — одна машина, увиденная с шести сторон: render вычисляет диф (прерываема, должна быть чистой), а commit его применяет (атомарна); двойная буферизация fiber делает прерывание бесплатным; ключи reconciliation привязывают состояние к идентичности, а не к позиции; lanes и time-slicing держат срочный ввод впереди дорогой работы; bailout — управляемый референциальной стабильностью через Object.is — держит большие деревья дешёвыми; а useSyncExternalStore не даёт внешним сторам делать tearing при concurrent rendering. Каждый продакшен-симптом здесь сводится к одному из этих шести рычагов.