reconcileChildren

Итак, произошло какое-то изменение, и мы в процессе создания нового FiberTree: обходим все узлы по порядку и создаем их свежие версии.

Новое дерево создается шаг за шагом, из текущего узла создаются дочерние, и возвращается первый из них - этим занимается функция reconcileChildren.

Она принимает:
⁃ старую (current) и новую (workInProgress) версию текущего fiber-узла
⁃ newChild - отрендеренный компонент для этого узла (renderWithHooks)
⁃ приоритеты рендеринга (lanes).

Функция определяет, что именно у нас отрендерилось в newChild, и на основе этого выбирает нужную ветку для создания нового FiberNode:

⁃ reconcileSingleElement - один дочерний элемент (REACT_ELEMENT_TYPE)
⁃ reconcileChildrenArray - массив дочерних элементов
⁃ reconcileSingleTextNode - текст

reconcileSingleElement

Создаем fiber, если у нас только один дочерний ReactElement.

⁃ проверяем, совпадает ли тип элемента со старой версией,

если да переиспользуем старый fiber (useFiber), если нет, удаляем старую версию, точнее помечаем для удаления (deleteChild)

⁃ удаляем все остальные дочерние элементы старой версии (если они были, т. е. если раньше было несколько элементов, а сейчас остался один) - deleteRemainingChildren.

reconcileChildrenArray

Тут много оптимизаций, связанных с порядком элементов (key) и переиспользованием старых узлов.

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

Тут также проставляются флаги:
⁃ для удаленных старых элементов (deleteChild)
⁃ для вставки новых элементов (placeChild)

Удаленные узлы

Важно: удаленные «старые» версии узлов пропадают из workInProgress-дерева. Но они сохраняются в свойстве deletions их родителя. Родителю проставляется флаг ChildDeletion и при коммите изменений все узлы из deletions будут удалены.

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

Чем полезен тип unknown?

Статья (англ.): https://michaeluloth.com/programming-types-unknown-why-useful/

Автор статьи напоминает нам, что мы не всегда можем быть уверены в типе данных, которые приходят из какого-то внешнего источника (пользовательский ввод или api). И советует использовать для таких данных тип unknown до тех пор, пока они не пройдут явную валидацию.

// не доверяем пришедшим данным
const getUserInput = (): unknown => {/*...*/}
 
const safe = () => {
  const data = getUserInput()
  
  if (typeof data === 'string') { // явно валидируем
    data.toUpperCase() // используем метод строки
  } else {
    // обрабатываем некорректный тип
  }
}

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

Пример не самый идеальный и в целом можно решать проблему неожиданных типов другими путями (например, использовать try-catch), но эта статья делает две хорошие вещи:

- раскрывает сущность типа unknown
- напоминает, что нельзя доверять чужим данным

#ссылки #typescript