​React Testing Library. Кастомный рендер

Мы можем настроить функцию render, передав вторым аргументом объект конфигурации. Например, можно добавить какую-то общую обертку с провайдерми для наших рендеров - параметр wrapper.

#тестирование #testinglibrary #документация #примерыкода

Render Hook

Помимо render у нас есть еще один метод - renderHook. Как можно догадаться, он предназначен для работы с хуками.

import {renderHook} from '@testing-library/react'

test('returns logged in user', () => {
  const {result, rerender} = renderHook((props = {}) => props, {
    initialProps: {name: 'Alice'},
  })
  expect(result.current).toEqual({name: 'Alice'})
  rerender()
  expect(result.current).toEqual({name: undefined})
})

Метод принимает два аргумента:
- рендер-функцию, которая должна вызвать хук и вернуть результат его работы
- объект конфигурации (опционально)

Результат работы хукуа будет доступен в поле result.current.

#тестирование #testinglibrary #документация #примерыкода

Руководство по React Testing Library

Статья (англ.): https://www.robinwieruch.de/react-testing-library/

Robin Wieruch по полочкам разложил, что такое RTL и как ей пользоваться.

1. RTL сама по себе не предназначена для организации тестов, поэтому нам в любом случае понадобится один тест-раннеров - Jest или Vitest. С их помощью напишем обертки тестов, а для конкретных действий уже будем использовать RTL.

2. В начале теста рендерим необходимые React-компоненты и сразу же перестаем о них думать как о React-компонентах. Мы должны тестировать обычный DOM, который видит пользователь.

3. RTL предоставляет огромное количество методов для поиска нужных элементов в отрендеренном фрагменте. Все они довольно подробно разобраны, кроме того, описано, когда и что предпочтительно использовать.

Запросы в testing-library

4. Пакет @testing-library/jest-dom добавляет множество удобных утверждений, вроде toBeInTheDocument.

5. Пользовательские события можно эмулировать с помощью fireEvent и user-event.

fireEvent
user-event

6. Разбираемся, как тестировать обработчики событий с помощью мокнутых функций.

7. И наконец учимся работать с асинхронными изменениями, например, сетевыми запросами, с помощью find-методов и waitFor. Не забываем мокать собственно методы, отправляющие запрос (axios/fetch/etc)

waitFor
пример тестирования компонента, выполняющего сетевой запрос


#ссылки #тестирование #testinglibrary

Testing Library. Полезные ресурсы

- документация Testing Library
- все существующие ARIA-роли для метода getByRole
- список утверждений, которые добавляются библиотекой @testing-library/jest-dom

#ссылки #тестирование #testinglibrary

Простое руководство по тестированию взаимодействия с пользователем с помощью библиотеки тестирования React

Статья (рус.): https://reddeveloper.ru/blog/363/prostoye-rukovodstvo-po-testirovaniyu-vzaimodeistviya-s-pol-zovatelem-s-pomoshch-yu-biblioteki-testirovaniya-react

Из этой статьи мы возьмем несколько примеров того, что в принципе можно тестировать, так как у меня по-прежнему есть сомнения и вопросы в этой области.

1. Поле ввода работают правильно

Имеем селект. Тестируем, что он работает правильно и выбранное пользователем значение действительно выбирается.

Полезные методы:
- getByRole('combobox')
- userEvent.selectOptiions
- expect(select).toHaveValue

2. При вводе/выборе значения оно корректно отображается в интерфейсе

Имеем селект города. Выводим выбранный город где-то в интерфейсе Тестируем, что при выборе города в селекте он изменяется и в интерфейсе.

Полезные методы:
- поиск элемента по тексту getByText
- поиск элемента другими методами, но с уточнением его текста (в настройках метода), например, getByRole('heading', { name: /moscow/i })

3. При ховере появляется элемент

Имеем тултип, который должен появляться при наведении на элемент. Тестируем, что он появляется.

Полезные методы:
- userEvent.hover
- expect(tooltip).toBeInTheDocument

4. Загрузка файлов

Проверяем, что загрузчик файлов видит загруженные файлы.

Полезные методы:
- new File(['hello'], 'hello.png', {type: 'image/png'})
- userEvent.upload(filePicker, file)
- expect(filePicker.files[0]).toEqual(file)

5. Отправка формы

Имеем форму. Тестируем, что при правильном заполнении полей форма успешно отправляется.

Также тестируем все варианты валидации:
- пустые поля
- некорректно заполненные поля

Полезные методы:
- userEvent.type(field, text)
- userEvent.selectOptions(select, option)
- userEvent.click(element)
- getByPlaceholderText(text)
- getByLabelText(text)

#ссылки #тестирование #testinglibrary

Разбираемся в React Concurrency

Статья (англ.): https://www.bbss.dev/posts/react-concurrency/

Конкурентный режим в React - фича уже не новая, но наверно еще не очень широко используемая. В статье дается хороший разбор.

Основная идея в том, что React научился прерывать рендеринг. Если у нас рендериттся что-то большое и тяжелое, пользователь не может взаимодействовать со страницей. Конкурентный режим как раз должен решать эту проблему.

Как именно эта фича реализована под капотом, в статье подробно не рассказывается. Упомянуто только, что в этом задействован пакет scheduler, а также, что используется requestAnimationFrame.

В общем, "конкурентного режима" как такового у нас нет, потому что его введение многое поломает. Вместо этого нам дали несколько "конкурентных фич", которые дают возможность избирательно запустить конкуррентный рендеринг.

useTransition

Хук useTransition возвращает метод startTransition. Он запускает transition, внутри которого все изменения будут считаться прерываемыми.

Если мы изменим стейт компонента внутри такого transition, изменения начнут применяться, но могут быть прерваны, если найдется более важное дело - например, действия пользователя.

Очевидно, что этот хук нам нужен только если мы контролируем изменения (сами их запускаем). Но как быть, если у нас нет возможности обернуть изменения в transition? Например, если мы получаем некоторое изменяющееся значение через проп.

useDeferredValue

Для этого случая есть хук useDeferredValue, который оборачивает это изменяющееся значение, но об изменениях сообщает нам только тогда, когда это ничему не мешает.

***

Таким образом, новые фичи позволяют нам явно помечать изменения как "неблокирующие". Также они работают с Suspense-компонентами.

#ссылки #concurrentmode

7 бесплатных шаблонов React для разработки проектов

Статья (рус.): https://nuancesprog.ru/p/15488/

Полноценные заготовки для проектов - чтобы не начинать работу с нуля. Есть шаблоны для лендингов, портфолио, блога, админ-панели...

#ссылки #инструменты

useEffect vs useLayoutEffect

Статья (англ.): https://kentcdodds.com/blog/useeffect-vs-uselayouteffect

Маленькое напоминание о разнице между двумя хуками.

useEffect срабатывает асинхронно после рендера компонента - пользователь уже увидел обновленный интерфейс, и только потом исполняется ваш код.

useLayoutEffect срабатывает синхронно. Новый DOM уже подготовлен, но браузер еще не перерисовал страницу для пользователя. В этот момент исполняется ваш код.

Обычно нам нужен useEffect, так как он неблокирующий и более эффективный, а у useLayoutEffect есть вполне конкретные кейсы:

- снять метрики (позиция скролла)
- обновить DOM до перерисовки так, чтобы пользователь не увидел мерцания
- установить какие-то актуальные значения, чтобы весь последующий код из useEffect мог их использовать

#ссылки #жизненныйциклкомпонента #хуки

React 19 будет компилируемым

Статья (англ.): https://reacttraining.com/blog/react-19-will-be-compiled

В феврале разработчики React рассказали, что работают над компилятором (React Compiler), который добавит в React автоматическую мемоизацию и сделает жизнь разработчиков проще (пост тут).

А в статье автор разбирается, что же это значит и насколько это нововведение изменит разработку.

Зачем мы мемоизируем

Одним из важных отличий классовых компонентов от функциональных было то, что рендер был вынесен в отдельный метод класса. Там был только код рендера и больше ничего. Когда ваш компонент перерендеривался, он не дергал никакого лишнего кода, как это происходит сейчас с функциональными компонентами.

При каждом рендере у нас создаются новые функции, новые объекты, которые не равны тем, что были в предыдущем рендере, а значит, могут ненароком вызвать лишние рендеры дочерних компонентов. Чтобы избежать этого, мы используем всякие useCallback'и и useMemo - занимаемся ручной мемоизацией.

В статье приводится простой пример этого процесса.

Компилятор вроде как должен избавить нас от этой мороки, будем надеяться, что эта задумка будет удачной.

Чуть более компилируемый

Затем автор рассуждает немного о "компилируемости" React. Он приходит к заключению, что нет двух отдельных положений - либо компилируется, либо не компилируется. Компилируемость - это шкала, на которой одни инструменты (Svelte) более компилируемы, а другие менее.

Идея в том, что появление нового компилятора не должно нас пугать.

#ссылки

Использование forwardRef с generic-компонентами

Статья (англ.): https://www.totaltypescript.com/forwardref-with-generic-components

Если вы часто используете generic-компоненты (которые могут работать с разными типами данных), то возможно уже сталкивались с проблемой с пробрасыванием рефа.

Если обернуть такой компонент в функцию React.forwardRef, то внутри него перестают выводиться типы.

👉 Компонент:

const Table = <T>(
  props: {
    data: T[];
    renderRow: (row: T) => React.ReactNode;
  },
  ref: React.ForwardedRef<HTMLTableElement>
) => {
  return (
    <table ref={ref}>
      <tbody>
        {props.data.map((item, index) => (
          <props.renderRow key={index} {...item} />
        ))}
      </tbody>
    </table>
  );
};
 
const ForwardReffedTable = React.forwardRef(Table);

👉 Использование:

<ForwardReffedTable
  data={[1, 2]}
  renderRow={(row) => {
    return <tr />;
  }}
/>

Мы передаем массив чисел в проп data и ожидаем, что для параметра row выведется правильный тип number, но этого не происходит.

👉 Решение:

Автор статьи предлагает сделать обертку над React.forwardRef, чтобы пофиксить это.

function fixedForwardRef<T, P = {}>(
  render: (props: P, ref: React.Ref<T>) => React.ReactNode
): (props: P & React.RefAttributes<T>) => React.ReactNode {
  return React.forwardRef(render) as any;
}

👉 Дополнительно:

- Перенаправление рефов

#ссылки #рефы

useActionState

В репозиторий реакт пару недель назад слили PR, в котором был немного изменен хук useFormState. Честно говоря, этот хук прошел полностью мимо меня, поэтому читаю как про совершенно новый хук)

Итак, у нас был какой-то useFormState, а стал useActionState, потому что все путались и думали, что можно работать только с формами. Оказывается, можно работать с любыми асинхронными экшенами.

Основная идея хука - отслеживать состояние экшена. Он возвращает три параметра:

const [state, action, isPending] = useActionState(someAsyncAction)

Action

action - это запуск экшена. То есть вместо того, чтобы напрямую вызывать someAsyncAction, мы вызываем предоставленный им action, так как в нем есть полезные оберточки.

Вызвать его можно прямо:

async function handleAction() {
  await action(someData)
}

А можно и традиционно засунуть в форму:

<form action={action}>

isPending

Как только запустился action, параметр isPending становится равен true. Как только action закончит свое выполнение, isPending станет false.

Таким образом мы можем отслеживать состояние экшена, работает он прямо сейчас или нет.

state

state - это результат работы экшена, то, что он вернул. Если вызовов было несколько, то результат работы последнего вызова.

Тут вроде ничего сложного нет, раньше мы самостоятельно накручивали подобный функционал вокруг какого-то вызова функции, теперь его накрутили за нас.

Конкуррентный рендеринг

Из приятного - под капотом используются transitions, то есть конкуррентный рендеринг.

Код выше можно переписать примерно вот так:

const [state, setState] = useState(null)
const [isPending, startTransition] = useTransition()

function handleAction() {
  startTransition(async () => {
    const response = await someAsyncAction({ userId: 222 })
    setState(response)
  })
}

Подводные камни

Есть и сложности, куда без них.

Так как неизвестно, используется ли isPending, он всегда устанавливается перед вызовом экшена, что приводит к дополнительному обновлению стейта (та же проблема есть и у хука useTransition).

#ссылки #хуки

​Как React работает под капотом. Обзор "внутренностей"

Статья (англ.): https://jser.dev/2023-07-11-overall-of-react-internals
Видео (англ.): https://youtu.be/fgxxoaeKQWo?si=2pSYXMZOoxROdh-q

Автор потратил много времени, разбираясь во внутренностях React, и наконец решил изложить все это в цикле статей. Это первая статья, в которой мы разбираемся, как работает React, на самом верхнем уровне.

Тут у нас есть 4 фазы.

1. Триггер

Мы сообщаем React, что нужно что-то отрендерить (начальный рендер) или перерендерить, потому что произошли изменения.

Грубо говоря, тут создается "таск" и отправляется в планировщик (Scheduler).

Здесь отрабатывают следующие методы:
- scheduleUpdateOnFiber()
- ensureRootIsScheduled()
- scheduleCallback()

2. Планирование

Планировщик - это очередь с приоритетами. Метод scheduleCallback добавляет новый таск в очередь, а затем он попадает в workLoop().

3. Рендер

На этом шаге вычисляется новое Fiber Tree (то, что раньше называлось Virtual DOM). Этот процесс теперь может прерываться (конкуррентный рендер).

Тут работает метод performConcurrentWorkOnRoot()

4. Коммит

И наконец вычисленные изменения вносятся в реальный DOM (comminMutationEffects()). Тут также выполняются все виды эффектов (flushPassiveEffects(), commitLayoutEffects()).

Статья хорошая, в начале автор разбирает, как именно происходит процесс дебаггинга React-приложения, и где какие методы выполняются.

#ссылки #подкапотом #fiber

Немного о Fiber

Суть работы React в том, что конечный интерфейс зависит от состояния, и при изменении состояния обновляется и интерфейс. Но он обновляется не полностью с нуля, а с огромным количеством оптимизаций. React вычисляет самый оптимальный способ обновить дерево компонентов, и для этого у него есть механизм Fiber.

Раньше был другой механизм, но его полностью переписали. Новый механизм Fiber обрабатывает изменения поэтапно, и между этапами его можно прервать. Это необходимо для реализации "конкурентных" фич React.

При каждом перерендере создается новое FiberTree, начиная от самого корня приложения/измененного элемента. Можно грубо сказать, что каждый Fiber соответствует React-компоненту. А в корне дерева находится FiberRoot.

Реконсилятор сравнивает новое дерево с текущим и вычисляет оптимальный набор обновлений. После внесения изменений (фаза commit), новое дерево само станет текущим.

В ближайших постах попробуем хотя бы в общих чертах разобраться, как именно это происходит:

- как движок узнает об изменениях
- как происходит обход дерева и реконсиляция
- как Fiber позволяет реализовать конкурентный рендеринг
и всякое такое

А для начала посмотрим, что из себя представляет отдельный файбер.

🪢 Fiber

Файбер - это минимальная единица работы при реконсиляции. По сути, обработка одного файбера - это обработка изменений одного компонента. То есть файбер описывает состояние компонента.

Файбер - это простой объект с кучей полей:

- tag - тип сущности, с которой связан файбер. Таких типов 28 (функциональный компонент, классовый компонент, провайдер-контекста, suspense и пр.). Отдельно отметим HostRoot (корень host-дерева) и IndeterminateComponent. При инициализации файбера в этом поле всегда будет IndeterminateCoomponent, пока не будет определен настоящий тип.

- type - тип самого файбера. Для функционального компонента это ссылка на конкретную функцию, для классового - на класс, для хука - указатель на хук, для HostRoot - конкретный тег и т.д.

- stateNode - ссылка на сопоставленную DOM-ноду.

- child, sibling, return - поля, обеспечивающие структуру FiberTree (наподобие связного списка). Файбер указывает на своего первого ребенка (child), на свой соседний файбер (sibling), а также на родителя, к которому нужно вернуться после выполнения компонента (return).

- memoizedProps, pendingProps - старые и новые пропы. При обработке они сравниваются и если изменений нет, можно сделать вывод, что компонент не изменился и не нужно тратить силы на его перерендер.

- flags, subtreeFlags - это битовая маска, в которой хранится информация о состоянии самого файбера и его поддерева. Информация записывается сюда после выполнения работы. Например, мы сравнили старые и новые пропы и увидели, что требуется обновить данный узел. Мы запишем сюда флаг UPDATE - узел требует перерендера. При дальнейшей обработке движок увидит этот флаг и сделает необходимые действия для перерендера.

- lanes, childLanes - тоже битовая маска, определяющая файбер в какой-либо лэйн (полосу). Это нужно для приоритизации задач - некоторые лэйны приоритетнее, чем другие.

- alternate - это копия файбера, в которой и происходят изменения во время реконсиляции. В сам файбер изменения вносятся только после коммита.

🪢 FiberRoot

Кроме обычных файберов есть еще FiberRoot, который соответствует корню приложения. У него еще больше полей, среди которых самое важное для нас:

- current - ссылка на файбер, который сейчас находится в работе. В процессе обхода дерева реконсилятором эта ссылка будет изменяться. Таким образом, корневой файбер хранит состояние всего обхода дерева.

#подкапотом #fiber

Первый рендеринг в React под капотом (начало)

Статья (англ.): https://jser.dev/2023-07-14-initial-mount/

Статья очень длинная, подробная, с большим количеством исходного кода React.

Создание root

Стандартное react-приложение начинается со следующего кода:

import { createRoot } from 'react-dom/client'

const $appContainer = document.getElementById('root')
const root = createRoot($appContainer)
root.render(children)

Прежде всего, вспоминаем, что react-dom - это рендер. React предоставляет весь функционал для работы с состоянием приложения, а рендеры делают обертки приложения для отрисовки в конкретной среде - в данном случае в браузере.

root - это объект ReactDOMRoot, обертка. Но под капотом у него - FiberTree. Оно представлено корневой нодой FiberRoot, а также Fiber-нодой корневого DOM-элемента (tag: HostRoot).

const hostRootFiberNode = {
  // ...
  tag: HostRoot,
}

const fiberRootNode = {
  // ...
  tag: ConcurrentRoot,
  containerInfo: $appContainer,
  current: hostRootFiberNode,
}

Триггер обновления

Когда мы вызываем метод root.render(children), он под капотом вызывает функцию updateContainer(children, fiberRootNode), передавая ей корень FiberTree.

Внутри этой функции происходит определение приоритета обновления (запрос лэйна). Если не ошибаюсь, то для первого рендера всегда будет DefaultLane, определяющий высокий приоритет и блокирующий синхронный рендеринг.

Здесь создается объект обновления update, который содержит информацию о приоритете и дочерних элементах, которые нужно вставить в хост-элемент.

Обновление ставится в очередь планировщика и планировщик запускается (`scheduleUpdateOnFiber`).

Таким образом, планировщик начал свой WorkLoop, и у него в очереди находится один апдейт - вставка компонента приложения в хостовый элемент.

На этом фаза триггера заканчивается.

#подкапотом #fiber #ссылки

Первый рендеринг в React под капотом (продолжение)

Статья (англ.): https://jser.dev/2023-07-14-initial-mount/

Цикл планировщика

Теперь перемещаемся в цикл обновлений и фазу рендера.

Тут сразу важно отметить, что у планировщика есть некоторое внутреннее состояние, в частности переменные workInProgressRoot и workInProgress.

Когда запускается процесс обновления состояния, планировщик получает FiberRootNode и копирует его в workInProgressRoot. Таким образом создается рабочая копия, в которую и вносятся все изменения, чтобы не затронуть актуальное дерево.

Начинается все в функции performConcurrentWorkOnRoot, которая хоть и имеет в названии слово concurrent, на самом деле не всегда запускает конкурентный рендеринг. Это зависит от приоритета (от параметра lane). Некоторые лэйны блокирующие, например, DefaultLane. Первый рендер всегда синхронный, поэтому запускается функция renderRootSync.

Тут у нас начинается цикл while, в котором за раз обрабатывается один юнит работы - то есть один файбер (метод performUnitofWork`). Текущий файбер хранится в переменной `workInProgress. После того как обработан текущий, туда кладется ссылка на следующий файбер в дереве, и цикл продолжается.

У нас пока один файбер: hostRootFiberNode.

beginWork

Основная работа происходит в функции beginWork(current, unitOfWork, renderLanes), где current - это текущее состояние (из текущего файбер-дерева), а unitOfWork обновленное.

Здесь по типу файбера определяется, как он будет рендериться. Наш файбер имеет тег HostRoot, поэтому его обработкой будет заниматься функция updateHostRoot(current, workInProgress, renderLanes).

Только тут мы наконец доходим до очереди обновлений и достаем ранее созданный апдейт (в фазе триггера). Вытаскиваем из него children и запускаем реконсиляцию потомков: reconcileChildren(current, workInProgress, children, renderLanes).

Здесь возможна вилка. Если текущего элемента еще нет (первая отрисовка элемента), то дети создаются с нуля (`mountChildFibers`). Если есть, значит это ререндер и дети обновляются (`reconcileChildFibers`). У корневого файбера всегда есть current-состояние (но current.child = null), поэтому идем по второй ветке.

Дальше идет много функций для создания/реконсиляции самых разных типов узлов, с большим количеством условий, думаю, в их логику можно не погружаться. Если интересно, в статье очень много исходного кода, можно проследить вплоть до рендера последней ссылочки.

Вкратце, для каждого компонента создается файбер (с учетом текущего состояния) и помещается в дерево.

Когда все поддерево файбера обработано, на нем вызывается метод completeWork, где создается DOM-нода, привязанная к этому файберу. (помним, что реализацию методов представления предоставляет рендер)

В итоге мы имеем полностью построенное обновленное FiberTree в переменной workInProgress - finishedWork. Все флаги, необходимые для превращения этого дерева в реальное представление расставлены (например, флаг, что элемент должен быть вставлен в DOM). Также подготовлены все необходимые DOM-узлы.

Фаза рендера закончена, переходим к коммиту изменений.

Коммит изменений

Тут происходят последние приготовления виртуального дерева, включая выполнение необходимых эффектов, привязку листнеров и т.п. И наконец привязка к реальному DOM.

#подкапотом #fiber #ссылки

Пожалуй, стоит все-таки чуть погрузиться в построение дерева компонентов при первом рендеринге, чтобы дальше было легче понимать, что происходит.

Рабочий цикл

Итак, React зашел в рабочий цикл и нашел наше запланированное обновление для HostRoot:

renderRootSync
    workLoopSync
        while(workInProgress) {
            performUnitOfWork(workInProgress)
        }

Здесь мы достаем children (App) и запускаем reconcileChildren на хост-элементе.

performUnitOfWork()
    beginWork()
        updateHostRoot()
            reconcileChildren()

Mount или Reconcile

Тут выполняется собственно реконсиляция. Если элемент монтируется в первый раз, вызывается mountChildFibers.

Но у HostRoot всегда есть current-состояние (хоть оно и равно null), поэтому мы пойдет по другой ветке - reconcileChildFibers. На самом функция там одна и та же (createChildReconciler), но разный входной параметр.

Результатом реконсиляции является файбер-нода для дочернего компонента App, которая будет возвращена из beginWork и станет следующей в очереди на обработку в цикле workLoopSync.

Реконсиляция и установка флагов

reconcileChildren
    reconcileChildFibers
        createChildReconciler(true)
            reconcileChildFibersImpl

Для разных типов узлов реконсиляция выполняется по-разному. В нашем случае это ReactElement (App):

case REACT_ELEMENT_TYPE:
  return placeSingleChild(
    reconcileSingleElement()
  )

Из reconcileSingleElement мы получаем один файбер с актуальным состоянием дерева. Если текущего элемента еще нет, как у нас, файбер просто создается с нуля (createFiberFromElement). Изначально он имеет неопределенный тип (IndeterminateComponent).

Затем в placeSingleChild файбер маркируется флагами для вставки в DOM. На флаги влияет обновляется ли файбер или создается с нуля. Для нашего файбера ставится флаг Placement (вставить в DOM).

Обход дерева, обработка компонентов

Итак, мы провели реконсиляцию для HostRoot и получили файбер для компонента App.

Цикл renderRootSync продолжается, теперь на очереди этот свежесозданный файбер App. Его тег еще не определен, поэтому работаетmountIndeterminateComponent.

performUnitOfWork
    beginWork
        mountIndeterminateComponent

Тут компонент рендерится (renderWithHooks), а также определяется его тег (FunctionComponent). И вызывается уже знакомый нам метод reconcileChildren - уже не для HostRoot, а для App.

Но в этом случае предыдущего состояния еще нет, поэтому отработает mountChildFibers:

reconcileChildren
    mountChildFibers
        createChildReconciler(false)

Для этого файбера не будет установлен флаг Placement, так как он маунтится с нуля.

Дальше цикл повторяется уже для нового файбера (потомка App). Для разных элементов будет отличаться путь обработки в beginWork:

funсtion beginWork() {
    case IndeterminateComponent:
        mountIndeterminateComponent()
    case HostComponent: // для HTML-тегов
        updateHostComponent() 
    case HostText: // для текстовых узлов
        updateHostText()
}

В итоге все равно запустится reconcileChildren для текущего узла и будет создан новый дочерний файбер.

Завершение обработки поддерева

После того, как будет достигнут последний элемент в дереве (лист), React начинает завершать файбер (completeUnitOfWork):

function performUnitOfWork(unitOfWork) {
    next = beginWork(current, unitOfWork, subtreeRenderLanes)

    if (next === null) {
        ...
    } else {
        workInProgress = next
    }
}

На этом этапе создается DOM-узел, связанный с файбером, и записывается в свойство stateNode.

При этом сначала завершается листовой файбер, React поднимается выше и завершает все родительский файбер. Если у него есть сиблинги, то React переходит к обработке соседнего поддерева. Когда завершится корневой файбер, обработка завершена - переходим к фазе коммита изменений.

Где именно происходит вот это завершение, пока не очень понятно - где-то внутри completeUnitOfWork.

#ссылки #fiber #подкапотом

Схема обновления дерева компонентов:

https://youtu.be/kNypR7QKixE?si=AZcFKvHjLSO_L3y5

#react #fiber #подкапотом

React Fiber & Concurrency. Часть 1

Статья (рус.): https://habr.com/ru/articles/763534/

Очень сложно у меня идет погружение во внутренности React, несколько раз уже хотела что-то резюмировать, но как будто пока особо нечего.

Поэтому вот неплохая статья с обзором механизма React Fiber, но без глубокого погружения в структуры и цепочки методов. Будем создавать устойчивую базу для дальнейшего понимания.

React Fiber

Главная задача, которую решило внедрение Fiber в React - инкрементальный рендеринг, на основе которого затем реализуется возможность неблокирующего рендеринга.

Весь процесс обновления дерева компонентов глобально состоит из двух фаз:

⁃ render (reconciliation) - тут применяются обновления, сравниваются старое и новое состояние и определяется, какую работу нужно выполнить, чтобы все обновить
⁃ commit - здесь вызываются хуки (или методы жизненного цикла), а также обновляется визуал (DOM).

Fiber Tree

Структура и состояние приложения хранится в виде Fiber Tree - причем таких деревьев у нас будет целых два: currentTree (текущее состояние, которое видит пользователь) и workInProgressTree (новое состояние, которое нужно применить).

У каждого дерева есть корень - FiberRoot, который создается в функции createWorkInProgress. При инициализации приложения (ReactDOM.createRoot) создается как раз этот корень для currentTree.

Каждый узел такого дерева - Fiber - это по сути минимальный кусочек работы (обновление компонента). Fiber создается на основе React Element (createFiberFromElement).

Первая фаза

Во время первой фазы (рендер) сначала создается корень для workInProgressTree на основе корня currentTree (createWorkInProgress).

Далее мы последовательно обходим дерево workInProgressTree, начиная с корня. и для каждого узла выполняем некоторую работу (performUnitOfWork). Внутри собственно и происходит вся работа по обновлению и реконсилляции.

Сначала происходит собственно обновление текущего активного узла - функция beginWork. Здесь выполняется вызов компонента (функционального или классового, не важно) и создание fiber-узла для него. Если Fiber создается впервые (нет соответствующего узла в currentTree), то срабатывает функция createFiberFromElement, иначе узел обновляется на основе старой версии в функции createWorkInProgress.

Далее переходим к первому ребенку текущего узла и обрабатываем его. Цикл продолжается, пока не попадется узел без детей (конец ветки). Тогда сработает функция completeUnitOfWork - завершение обработки «ветки». В ней происходит «всплытие» до первого родительского элемента, которого есть необработанный сиблинг, то есть цикл продолжится на следующей ветке.

В процессе обновления заполняются поля flags и subtreeFlags - это пометки о том, какие действия нужно будет провести над этими узлами в фазе коммита изменений (например, есть флаги, указывающие, что нужно сделать снапшот - Snapshot или обновить узел - Update). Логично, что subtreeFlags заполняется во время всплытия (completeeUnitOfWork), когда поддерево узла уже обработано и все флаги для дочерних узлов проставлены.

Также в completeUnitOfWork модифицируется DOM-элемент, соответствующий узлу (он записывается в поле stateNode).

Вторая фаза

К этому моменту полностью сформировано обновленное дерево workInProgressTree, которое записывается в переменную finishedWork.

Здесь будет происходить обработка на основе ранее проставленных флагов. Действия выполняются в следующем порядке:

⁃ commitBeforeMutationEffects - действия перед обновлением DOM (снапшоты)
⁃ commitMutationEffects - изменения DOM (отрисовка происходит позже, когда у браузера будет возможность)
⁃ commitLayoutEffects - выполнение хуков useLayoutEffect
⁃ flushPassiveEffects - выполнение хуков useEffect

С помощью флагов React находит в дереве узлы, с которыми нужно выполнить то или иное действие (используется двоичная маска).

#ссылки #fiber #подкапотом

Инициализация React-приложения и запуск первого рендера (верхнеуровневый обзор)

Еще одно небольшое верхнеуровневое резюме по самому первому этапу работы React-приложения (инициализация и запуск первого рендера).

Основано на:
👉 How createRoot works
👉 How root.render() works
👉 How root render schedule works

Начало

Начинается все с простого синхронного кода:

import { App } from "./app";
import { createRoot } from "react-dom/client";

const container = document.getElementById("root");

// 1
const root = createRoot(container);
// 2 
root.render(<App />);

1 - Создание корня

На первом шаге мы создаем «корень React-приложения» - структуру ReactDOMRoot, которая содержит ссылку на FiberTree всего приложения.

FiberTree состоит из отдельных файберов FiberNode, а на самом верху у него корневой файбер FiberRootNode.

При создании у нас уже есть корневой файбер + еще один обычный файбер, соответствующий корневому DOM-элементу, в который и будет рендериться наше React-приложение - нужно же с чего-то начинать. Этот файбер хранится в поле current нашего файбер-дерева.

2 - Запуск рендера

На втором шаге мы впервые запускаем процесс обновления приложения. Сейчас вручную, а дальше это будет происходить автоматически при изменениях, например, стейта. За это отвечает функция updateContainer.

Обновление начинается с самого верха - с корня файбер-дерева и того самого предзаготовленного первого файбера из поля current.

React определяет полосу (приоритет) обновления для этого файбера (lane) - при первом рендере приоритет очень высокий.

Затем создается объект обновления (Update), где сохраняются все необходимые данные (ссылка на файбер, приоритет и собственно содержимое (children - <App />), которое нужно вставить в контейнер.

Объект обновления сохраняется внутри файбера в очереди обновлений (updateQueue).

Само обновление будет происходить позже и вообще в другом месте - внутри цикла React. Поэтому сейчас его нужно только оформить и запланировать - чтобы цикл потом мог его найти.

Этим занимается функция scheduleUpdateOnFiber. Она планирует микротаск, который будет выполняться сразу после того, как закончится синхронный код. Как именно планируется микротаск, кажется, определяет сам рендерер для конкретного окружения (например, ReactDOM использует для планировки промисы). Тут важно, что обновление добавлено в Event Loop. Собственно момент планировки происходит в функции scheduleImmediateTask.

Когда все запланировано, запускается синхронный WorkLoop (функция `flushSyncWorkOnAllRoots`), и это уже совсем другая история.

#подкапотом #fiber #ссылки

​Как React обходит Fiber-дерево?

Статья (англ.): https://jser.dev/react/2022/01/16/fiber-traversal-in-react/

Очень маленькая статья, описывающая алгоритм обхода FiberTree в React.

Каждый узел дерева имеет поля child, sibling и return, то есть хранит ссылку на первого ребенка, следующего соседа и родителя.

При обходе мы сначала спускаемся до самого низа ветки по цепочке child'ов, а когда дети заканчиваются, завершаем обработку текущего узла и поднимается на уровень выше (по ссылке в return). Обработку родительского узла также завершаем. Здесь мы проверяем, есть ли сиблинг, если есть, идем к нему, если нет, поднимаемся еще на уровень выше.

В конце концов мы дойдем до самого низа самой правой ветки и оттуда поднимемся к корню дерева, у которого ничего нет в свойстве return - обход окончен.

#ссылки #подкапотом #fiber

Первый рендеринг в React: общее понимание

Еще одна попытка разобраться в подкапотье механизма Fiber. На примере самого первого рендера.

Статья (англ.): https://jser.dev/2023-07-14-initial-mount/#311-updatehostcomponent

1. Создание FiberRoot

Повторю еще раз на всякий. Начинается все с того, что мы создаем FiberRoot, от которого потом будет расти все дерево приложения.

import { createRoot } from 'react-dom/client'
const $appContainer = document.getElementById('app’)
const root = createRoot($appContainer)

На данный момент наше дерево представлено корнем FiberRoot, а также одним обычным Fiber типа HostRoot - он соответствует HTML-контейнеру приложения - тегу #app.

2. Триггер и планирование обновления

Первое обновление запускаем вручную, дальше они будут вызваться автоматически при изменении состояния компонентов, но это нам сейчас неинтересно:

root.render(‘<App />’)

Тут создается объект обновления для Fiber:HostRoot, внутри которого сохраняется элемент, который нужно отрендерить (<App />). Обновление помещается в очередь обновлений для Fiber:HostRoot (updateQueue).

На данном этапе обновление не происходит - оно только планируется на будущее.

Весь код до этого момента - синхронный.

3. Рабочий цикл планировщика

Переходим к циклу. У нас есть обновление, поэтому нужно создать новое Fiber-дерево. Буквально новое и прямо от корня - это новое дерево называется workInProgress.

Создаем новый Fiber:HostRoot - и начинаем цикл прямо с него.

На каждой итерации мы берем текущий Fiber-узел и - внимание! - создаем его child-узел. То есть с каждым шагом наше workInProgress-дерево растет.

Это делает функция beginWork - создает и возвращает дочерний узел, который станет текущим в следующей итерации цикла.

При создании child-узла для нового дерева обязательно учитывается, если у него уже есть текущая версия в current-дереве. Если есть, то старый узел будет обновлен, если еще нет, то узел будет создан заново из React-элемента.

Последовательность обхода дерева описана в предыдущем посте - сначала мы спускаемся вниз по дочерним узлам (сначала создаем дочерний узел, потом сразу же к нему переходим). Это фаза собственно «рендера» или «реконсиляции» - расчет изменений.

Как именно создается дочерний узел, зависит от типа текущего узла. Для HostRoot данные для рендера (дочерние элементы) достаются из того самого объекта обновления, который был создан и запланирован в самом начале. Для других узлов в основном берутся из пропсов (props.children).

Когда достигнут низ ветки и детей больше нет, начинаем подниматься вверх и искать первый узел, у которого есть сиблинг. При этом мы последовательно «закрываем» все узлы, которые уже были обработаны (снизу вверх) - это делает функция completeUnitOfWork.

На этом «обратном» пути для каждого узла создается соответствующий DOM-элемент, который пока просто сохраняется в поле stateNode, а потом будет вставлен в реальный DOM.

Также во время спуска и подъема проставляются разнообразные флаги, которые затем будут использоваться для обновления DOM (например, что узел нужно удалить или наоборот вставить в документ).

4. Коммит изменений в DOM

Итак, мы обошли все дерево, и теперь у нас есть полностью построенное дерево workInProgress, где для каждого узла проставлены флаги, что с ним нужно делать (например, вставить в DOM или удалить).

Теперь мы реально будем менять DOM - сначала удалять, потом вставлять и менять порядок, потом запускать эффекты.

Дерево workInProgress теперь становится деревом current.

#ссылки #fiber #подкапотом