Forem: jennypollard

Что делает React Compiler?

jennypollard — Wed, 15 Jan 2025 19:14:28 +0000

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

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

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

Мемоизация результата рендера

Результатом рендера я называю выражение, которое возвращается из компонента: return <div>{items}</div>, в этом примере <div>{items}</div> - результат рендера. Результат рендера зависит от пропсов и промежуточных значений, вычисленных внутри компонента. Назовем эти значения зависимостями выражения. Когда результат рендера остается постоянным при одних и тех же зависимостях, вычисление выражения можно пропустить. Для этого Реакт Компилятор вставит код, запоминающий последний результат вычисления:

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

Такой компонент:

function Div({ item, other }) {
  return <div data-x={other}>{item}</div>;
}

Реакт Компилятор преобразует вот так:

import { c as _c } from "react/compiler-runtime";
function Div(t0) {
  const $ = _c(3);
  const { item, other } = t0;
  let t1;
  if ($[0] !== item || $[1] !== other) {
    t1 = <div data-x={other}>{item}</div>;
    $[0] = item;
    $[1] = other;
    $[2] = t1;
  } else {
    t1 = $[2];
  }
  return t1;
}

Можно догадаться, что в строке const $ = _c(3) Реакт Компилятор создает локальный кэш на 3 элемента. В действительности, c из react/compiler-runtime вызывает внутри себя React.useMemo.

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

Код в примере выше аналогичен оборачиванию компонента в memo.

Мемоизация выражений

В примере выше, jsx-выражение зависило только от пропсов компонента. Часто в компонентах вычисляются промежуточные значения, которые подставляются в jsx-выражения. Эти промежуточные значения также могут быть мемоизированы. Для этого Реакт Компилятор определит зависимости выражения и вставит код для кэширования всего выражения на основе этих зависимостей.

Рассмотрим пример, в котором внутри компонента происходит вычисление:

export default function App(props) {

  const name = props.fullname.split(' ')[0];

  return <main>
    {name}
  </main>;
}

В этом примере <main>{name}</main> - это jsx-выражение, его зависимость - переменная name, которая в свою очередь вычисляется выше выражением props.fullname.split(' ')[0]. Выражение props.fullname.split(' ')[0] зависит только от пропсы fullname.
Реакт Компилятор преобразует этот компонент следующим образом:

import { c as _c } from "react/compiler-runtime";
export default function App(props) {
  const $ = _c(4);
  let t0;
  if ($[0] !== props.fullname) {
    t0 = props.fullname.split(" ");
    $[0] = props.fullname;
    $[1] = t0;
  } else {
    t0 = $[1];
  }
  const name = t0[0];
  let t1;
  if ($[2] !== name) {
    t1 = <main>{name}</main>;
    $[2] = name;
    $[3] = t1;
  } else {
    t1 = $[3];
  }
  return t1;
}

Реакт Компилятор закэширует props.fullname и результат вычисления name. Если пропса fullname поменяется, выражение будет вычислено и закэшировано еще раз. Этот код аналогичен оборачиванию вычисления name в useMemo в исходном компоненте:

import {useMemo} from 'react';

export default function App(props) {

  const name = useMemo(() => props.fullname.split(' ')[0], [props.fullname]);

  return <main>
    {name}
  </main>;
}

Включение Реакт Компилятора может не принести ощутимой пользы в проекте, в котором осознанно используются useMemo и memo.

Техника Помодоро vs Результат

jennypollard — Sat, 30 Nov 2024 21:27:33 +0000

Долой помодоро. Занималась задачей полчаса, сфокусированно, результата нет, но есть обманчивое ощущение что делаешь все правильно. Одна помидорка в день, десять помидорок в день, так несколько дней и нет результата. Но есть помидорки. Не работает.

Нужен результат, маленький результат прямо сейчас, хоть два предложения, хоть понимание следующего шага, хоть строчка кода. За 25 минут, или за 5, или за 77, если требуется. Но нужен результат.

Какая разница, 20 минут помидорка, 25 или 30? Какая разница какой перерыв отдыха между ними? Какая разница какое ты используешь приложение?

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

React Signals: как устроены сигналы в React

jennypollard — Fri, 28 Apr 2023 13:46:48 +0000

Следуя трендам, можно было обнаружить для себя React Signals. Возможно, вам попадался такой фрагмент кода:

import { signal } from "@preact/signals-react";

const count = signal(0);

export default function App() {
  return <button onClick={() => count.value++}>{count.value}</button>;
}

Код вызывает удивление — как это сделано? Почему App обновляется при изменении count? Что позволило так сделать? Похоже на хуки, но нет, хуки нельзя использовать вне компонента…

Найдем код `@preact/signals-react`

Пакеты берутся из npm-реестра, найдем @preact/signals-react на npmjs.com. На странице пакета есть ссылка на репозиторий модуля на GitHub. В репозитории есть несколько директорий: docs, patches, scripts, packages. Первые три нам сейчас не интересны — это документация и какие-то вспомогательные вещи, посмотрим в packages. В packages есть core, preact, react. preact — нас сейчас не интересует, core — нечто очень важное и общее, но нам нужно конкретное — react. Внутри найдем src/index.ts.

С чего начать — код выполняемый при инициализации модуля

Разберемся, что происходит при инициализации модуля, посмотрим, что делает код, выполняемый при импорте модуля. Проигнорируем, для начала, определения функций и внутренних переменных, у нас останется:

const JsxPro: JsxRuntimeModule = jsxRuntime;
const JsxDev: JsxRuntimeModule = jsxRuntimeDev;
React.createElement = WrapJsx(React.createElement);
JsxDev.jsx && /*   */ (JsxDev.jsx = WrapJsx(JsxDev.jsx));
JsxPro.jsx && /*   */ (JsxPro.jsx = WrapJsx(JsxPro.jsx));
JsxDev.jsxs && /*  */ (JsxDev.jsxs = WrapJsx(JsxDev.jsxs));
JsxPro.jsxs && /*  */ (JsxPro.jsxs = WrapJsx(JsxPro.jsxs));
JsxDev.jsxDEV && /**/ (JsxDev.jsxDEV = WrapJsx(JsxDev.jsxDEV));
JsxPro.jsxDEV && /**/ (JsxPro.jsxDEV = WrapJsx(JsxPro.jsxDEV));

// Decorate Signals so React renders them as <Text> components.
Object.defineProperties(Signal.prototype, {
    $$typeof: { configurable: true, value: ReactElemType },
    type: { configurable: true, value: ProxyFunctionalComponent(Text) },
    props: {
        configurable: true,
        get() {
            return { data: this };
        },
    },
    ref: { configurable: true, value: null },
});

Последний блок кода (с Object.defineProperties) добавляет всем сигналам возможность рендериться: $$typeof, type, props, ref — свойства всех React-элементов.

Остановимся подробней на первой части, в ней участвуют: jsx, jsxs (из react/jsx-runtime), jsx, jsxs (из react/jsx-dev-runtime), createElement из React и некая функция WrapJsx.

Что такое jsx-runtime?

React-компоненты преобразуются в вызовы React.createElement, jsx или jsxs

Например, такой код:

const Foo = () => (<button>Click Me</button>);

const Bar = () => (
  <div>
    <Foo />
  </div>
);

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

import { jsx as _jsx } from "react/jsx-runtime";
const Foo = () =>
    _jsx("button", {
    children: "Click Me"
  });
const Bar = () =>
    _jsx("div", {
    children: _jsx(Foo, {})
  });

В зависимости от настроек js-компилятора (например, babel), вместо React.createElement может быть jsx из react/jsx-runtime, будем считать их эквивалентными.

React.createElement — это функция создающая React-элемент. У нее три аргумента: type, config, children. Первый аргумент type — это тип элемента, может быть:

строкой — для хост-элеметов: div, span, main;
объектом — в случае экзотичных React-элементов: forwardRef, memo;
функцией — для функциональных или класс-компонентов.

Второй аргумент config — это объект, содержащий в себе пропсы элемента, ref и key.

Последний аргумент children — список дочерних элементов. Точно такую же роль выполняют функции jsx, jsxs, jsxDev — создают React-элементы, имеют такие же аргументы.

Вернемся к коду инициализации модуля:

const JsxPro: JsxRuntimeModule = jsxRuntime;
const JsxDev: JsxRuntimeModule = jsxRuntimeDev;
React.createElement = WrapJsx(React.createElement);
JsxDev.jsx && /*   */ (JsxDev.jsx = WrapJsx(JsxDev.jsx));
JsxPro.jsx && /*   */ (JsxPro.jsx = WrapJsx(JsxPro.jsx));
JsxDev.jsxs && /*  */ (JsxDev.jsxs = WrapJsx(JsxDev.jsxs));
JsxPro.jsxs && /*  */ (JsxPro.jsxs = WrapJsx(JsxPro.jsxs));
JsxDev.jsxDEV && /**/ (JsxDev.jsxDEV = WrapJsx(JsxDev.jsxDEV));
JsxPro.jsxDEV && /**/ (JsxPro.jsxDEV = WrapJsx(JsxPro.jsxDEV));

Теперь понятно, что модуль переопределяет функции создания React-элементов результатом вызова функции WrapJsx. Каждая функция: jsx, jsxs, jsxDEV, createElment преобразуется с помощью WrapJsx.

Что делает функция-декоратор `WrapJsx`?

Посмотрим код функции WrapJsx:

function WrapJsx<T>(jsx: T): T {
    if (typeof jsx !== "function") return jsx;

    return function (type: any, props: any, ...rest: any[]) {
        if (typeof type === "function" && !(type instanceof Component)) {
            return jsx.call(jsx, ProxyFunctionalComponent(type), props, ...rest);
        }

        if (type && typeof type === "object") {
            if (type.$$typeof === ReactMemoType) {
                type.type = ProxyFunctionalComponent(type.type);
                return jsx.call(jsx, type, props, ...rest);
            } else if (type.$$typeof === ReactForwardRefType) {
                type.render = ProxyFunctionalComponent(type.render);
                return jsx.call(jsx, type, props, ...rest);
            }
        }

        if (typeof type === "string" && props) {
            for (let i in props) {
                let v = props[i];
                if (i !== "children" && v instanceof Signal) {
                    props[i] = v.value;
                }
            }
        }

        return jsx.call(jsx, type, props, ...rest);
    } as any as T;
}

WrapJsx вызывается с единственным аргументом jsx — оригинальной функцией создания React-элемента и возвращает функцию с такими же как у jsx аргументами.

WrapJsx обрабатывает четыре сценария:

Функциональный компонент или класс-компонент:

if (typeof type === "function" && !(type instanceof Component)) {
    return jsx.call(jsx, ProxyFunctionalComponent(type), props, ...rest);
}

Если создается React-элемент, тип у которого — функция, значит элементу соответствует фукнциональный компонент или класс-компонент. Например, для такого jsx-выражения: <div><Foo>text</Foo></div> под условие выше подходит Foo. Внутри условия вызывается оригинальная функция jsx, но вместо исходного type передается ProxyFunctionalComponent(type), это эквивалентно оборачиванию Foo в ProxyFunctionalComponent:

const Foo = ProxyFunctionalComponent(props => {
    return (
        ...
    );
})

Экзотичные React-элементы:

if (type && typeof type === "object") {
    if (type.$$typeof === ReactMemoType) {
        type.type = ProxyFunctionalComponent(type.type);
        return jsx.call(jsx, type, props, ...rest);
    } else if (type.$$typeof === ReactForwardRefType) {
        type.render = ProxyFunctionalComponent(type.render);
        return jsx.call(jsx, type, props, ...rest);
    }
}

Если тип элемента — объект, значит создается экзотичный React-элемент, их два: memo и forwardRef. Оба эти элемента ссылаются на функциональный компонент, который нужно отрендерить. Элемент memo ссылается на компонент через свойство type, forwardRef ссылается через свойство render. Во фрагменте выше, они также оборачиваются в ProxyFunctionalComponent.

Хост-компоненты.

Хост-компоненты (div, span, main и тд) попадают в третью ветку, в этом случае type — это строка.

if (typeof type === "string" && props) {
    for (let i in props) {
        let v = props[i];
        if (i !== "children" && v instanceof Signal) {
            props[i] = v.value;
        }
    }
}

Для таких элементов просматривают все пропсы и, если среди них есть экземпляр Сигнала, он заменяется на его значение value.

Таким образом, декоратор WrapJsx оборачивает все пользовательские компоненты в ProxyFunctionalComponent. При каждом обновлении (рендере) пользовательского компонента будет сначала происходить вызов ProxyFunctionalComponent. Так как можно быть уверенным, что это происходит в момент обновления, внутри ProxyFunctionalComponent можно использовать хуки, создавать локальный компоненту стейт, подписываться на события. @preact/signals-react использует эту возможность, чтобы отслеживать обращения к Сигналам внутри компонента и вызывать обновление компонента, когда Сигнал изменяется.

npm i или npm ci?

jennypollard — Thu, 23 Feb 2023 13:38:09 +0000

npm i vs npm ci — какую команду использовать.

npm i (npm install)

npm i устанавливает пакеты и их зависимости в директорию node_modules. По-умолчанию, список пакетов берется из раздела dependencies в package.json.

npm обновляет файл package-lock.json после любых измений package.json или node_modules. То есть, если в результате выполнения какой-либо команды npm, будет обновлен package.json или содержимое node_modules, то будет обновлен package-lock.json.

package-lock.json описывает фактическое дерево пакетов, которое было уставновлено и нужен для того, чтобы выполнение npm i приводило к одному и тому же набору пакетов. Другими словами, package-lock.json это описание того, что установлено в node_modules.

npm i может устанавливать пакеты по-одному, по-умолчанию npm i добавляет установленный пакет в раздел dependencies (и обновляет package-lock.json).

npm ci

Команда npm ci похожа на npm i — тоже устанавливает зависимости, но предназначена для установки зависимостей с чистого листа — при сборке приложения, в релизных пайплайнах, в проверках пулреквестов, используется автоматикой. npm ci быстрее, чем npm i и имеет существенные отличия:

удаляет node_modules перед установкой.
npm ci требует для работы наличие package-lock.json, иначе получим ошибку:

npm ERR! cipm can only install packages with an existing package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or later to generate it, then try again.

npm ci не может устанавливать пакеты по-одному, устанавливает все сразу как описано в package-lock.json.
npm ci не обновляет package-lock.json и package.json, так как предназначен для автоматики, а в этом случае репозиторий только на чтение.
если версии пакетов в package.json и package-lock.json расходятся, команда завершится с ошибкой:

npm ERR! cipm can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing.
npm ERR! Invalid: lock file's lodash.get@4.4.2 does not satisfy lodash.get@4.4.0

Иногда в node_modules могут накапливаться проблемы (например, рассинхрон фактических и ожидаемых версий пакетов), для таких случаев npm ci — быстрый способ переустановить все зависимости.

Photo by Paul Teysen on Unsplash

О чем написать пост - Выбираем тему для поста

jennypollard — Sat, 28 Jan 2023 14:28:23 +0000

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

Рецепты

В среде в которой мы работаем, часто возникают вопросы у коллег — как добиться какого-то поведения в коде. Эти вопросы могут служить темой для поста. Ответь для себя на такой вопрос, сделай минимальный пример. С примерами может помочь codesandbox или stackblitz.

Еще источником вдохновения могут служить вопросы и комментарии на stackoverlow или аналогичных платформах. Можно дать новую жизнь своим ответам или найти интересную идею в комментариях к вопросам и ответам.

Покопаться в исходниках

Каждый день мы используем какой-нибудь фреймворк, технологию. Используем какие-то функции, возможно, моделируя для себя их реализацию на основе их поведения и прочитанного в документации — для нас они черный ящик. Можно заглянуть “под капот”, найти реализацию в исходниках, доуточнить свою модель и рассказать об этом.

Ограничить усилия сверху

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

Продолжай писать…

Что такое React Fiber - React Fiber Architecture

jennypollard — Thu, 29 Dec 2022 13:25:50 +0000

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

Перевод статьи Эндрю Кларка “React Fiber Architecture” https://github.com/acdlite/react-fiber-architecture

Введение

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

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

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

Об этом документе

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

Автор попытается использовать самый ясный язык, насколько это возможно, и попытается давать ясные определения ключевым терминам, вместо использования жаргона.

Пожалуйста, имейте в виду, что автор не входит в команду React и не говорит от имени команды. Это неофициальный документ. Автор просил членов команды React проверить этот документ на предмет неточностей.

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

Цель автора — сформировать понимание архитектуры Fiber достаточное для того, чтобы ориентироваться в его изменениях по мере развития, и, в конечном счете, чтобы быть способным внести свои изменения в React.

Перед тем как начать…

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

React Components, Elements, and Instances. Компонент — часто перегруженный термин, важно уверенно понимать, что он означает.
Reconciliation. Высокоуровневое описание алгоритма реконсилиации.
React Basic Theoretical Concepts. Описание концептуальной модели React неотягощенная реализацией. Что-то из этого может быть непонятно при первом чтение — это нормально, станет понятней позже.
React Design Principles. Обратите особое внимание на раздел про планирование — в нем даны хорошие объяснения причинам, стоящим за React Fiber.

Обзор

Пожалуйста, ознакомьтесь с разделом “Перед тем как начать”, если вы этого еще не сделали.

Перед тем как погрузиться в новые вещи, давайте вспомним несколько концепций.

Что такое реконсилиация?

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

Обновление — изменение в данных используемых для отрисовки приложения. Обычно, это результат вызова setState. В конечном счете обновление приводит к переотрисовке.

Центральная идея API React-а — считать что обновления вызывают переотрисовку всего приложения. Это позволяет разработчикам рассуждать декларативно, вместо того, чтобы беспокоиться о том, как эффективно перевести приложение из одного состояния в другое.

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

Реконсилиация это алгоритм лежащий в основе виртуального DOM. Высокоуровневое описание примерно такое: когда отрисовывается React приложение, генерируется дерево структур описывающих приложение и сохраняется в памяти. Это дерево затем отправляется среде отрисовки — например, в случае браузерного приложения, дерево переводится в набор операций над DOM. Когда приложение обновляется (обычно из-за setState), генерируется новое дерево. Новое дерево сравнивается с предыдущим для определения, какие операции нужны, чтобы обновить отрисованное приложение.

Хотя Fiber это попытка переписать с нуля реконсилятор, высокоуровневое описание алгоритма в документации React будет почти такое же. Ключевые моменты такие:

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

Реконсилиация vs Отрисовка

DOM браузера это только одна из сред отрисовки в которой может работать React, отрисовка в других средах, iOS и Android, достигается средствами React Native. По этой причине термин “виртуальный DOM” немного некорректен.

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

Это разделение на механизмы отрисовки и реконсиляции означает, что React DOM и React Native могут использовать собственные отрисовщики и один и тот же реконсилятор, предоставленный React.

Fiber — новый реконсилятор. В основном, реконсилятор не связан с отрисовкой, хотя отрисовщикам нужно будет поддержать новую архитектуру и воспользоваться её преимуществами.

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

Планирование — процесс определения когда работа должна быть выполнена.

Работа — любые вычисления, которые должны быть выполнены. Работа это обычно результат обновления (например, по причине вызова setState).

Принципы Архитектуры React задокументировали это настолько хорошо, что можно привести цитату:

В текущей реализации React обходит дерево элементов рекурсивно и вызывает функцию отрисовки всего обновленного дерева в течение одного тика. Однако, в будущем React может откладывать некоторые обновления, чтобы избежать падения частоты кадров.
Это основной мотив архитектуры React. Некоторые популярные библиотеки реализуют push-подход, когда вычисления происходят по мере поступления новых данных. Однако React придерживается pull-подхода, когда вычисления могут быть отложены до того момента, когда они необходимы.
React это не универсальная библиотека для обработки данных, это библиотека для построения пользовательских интерфейсов. Мы думаем, что React занимает однозначное место в приложении, чтобы знать, какие вычисления сейчас уместны, а какие нет.
Если что-то находится за пределами экрана, мы можем отложить логику связанную с этим. Если данные прибывают быстрее, чем частота кадров, мы можем объединять обновления в группы. Чтобы избежать падение частоты кадров, мы можем отдавать приоритет работе связанной со взаимодействием пользователя с интерфейсом (например, анимация вызванная нажатием на кнопку), чем менее важной фоновой работе (например, отрисовка нового контента разгруженного из сети).

Ключевые вещи:

В пользовательском интерфейсе нет необходимости применять каждое обновление сразу — это может быть нерациональным и быть причиной для потери частоты кадров и ухудшения пользовательского опыта.
У разных типов обновлений, разные приоритеты. Обновление связанное с анимацией должно быть выполнено быстрее, чем, скажем, обновление из хранилища данных.
Push-подход требует от приложения (от разработчика) решить, как спланировать работу. Pull-подход позволяет фреймворку (React) быть умнее и принимать такие решения за разработчика.

Сейчас React не пользуется преимуществами планирования в значительной степени. Обновление немедленно приводит к полной перерисовке поддерева. Реконструирование основного алгоритма React так, чтобы воспользоваться преимуществами планирования — это движущая идея Fiber.

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

Что такое файбер?

Мы приступаем к обсуждению центральной части архитектуры React Fiber. Файбер (fiber) — это абстракция более низкого уровня, чем обычно думают разработчики приложений. Если вы отчаялись в попытках понять ее, не разочаровывайтесь. Пробуйте и в конечном счете будет понятно. (Когда станет, пожалуйста, предложите как улучшить этот раздел.)

Поехали!

Мы определили, что главная цель Fiber — дать возможность React воспользоваться преимуществами планирования. В частности, нам нужно иметь возможность:

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

Чтобы это сделать, в первую очередь нам нужен способ разделить работу на блоки. В некотором смысле, файбер является таким блоком. Файбер представляет собой единицу работы.

Чтобы двигаться дальше, вернемся к концепции “React-компонент как функция от данных”, которая обычно выражается как v = f(d).

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

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

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

Более новые браузеры (и React Native) реализуют API, которое учитывает эту проблему: requestIdleCallback планирует выполнение менее приоритетных функций во время периода бездействия, а requestAnimationFrame планирует более приоритетные функции во время следующего кадра анимации. Проблема в том, что для использования этого API нужен способ разделить работу по отрисовке на инкрементальные единицы. Если полагаться только на стек вызовов, работа будет выполняться пока стек вызовов не опустеет.

Правда было бы круто, если бы мы могли приспособить стек вызовов так, чтобы оптимизировать отрисовку интерфейса? Было бы супер, если бы мы могли произвольно прерывать стек вызовов и управлять фреймами стека вручную?

Это и есть цель React Fiber. Файбер — это реализация стека вызовов, специализированная для React-компонентов. Единичный файбер можно считать виртуальным фреймом стека.

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

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

В следующем разделе мы подробнее рассмотрим структуру файбера.

Структура файбера

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

Файбер соответствует фрейму стека, но также соответствует экземпляру компонента. Перечислим некоторые важные поля файбера (не все):

`type` и `key`

type и key служат такой же цели, как и в случае React-элемента. Фактически, когда файбер создается из элемента, эти два поля просто копируются из него.

type ссылается на компонент соответствующий файберу. Для составных компонентов, type это функция или класс компонента. Для хост-компонентов (div, span и так далее), type это строка.

Концептуально, type это функция (как в v = f(d)), выполнение которой отслеживается стековым фреймом.

Вместе с полем type, поле key используется во время реконсилиации для определения того, можно ли переиспользовать результат файбера.

`child` и `sibling`

Эти два поля ссылаются на другие файберы и описывают древовидную структуру файбера.

Поле child (потомок) ссылается на файбер, соответствующий результату функции render компонента. Например:

function Parent() {
    return <Child />
}

здесь, Child будет файбером-потомком для Parent.

Поле sibling (элемент того же уровня) учитывает случай, когда render возвращает несколько потомков:

function Parent() {
    return [<Child1 />, <Child2 />]
}

Поле child ссылается на первый файбер в односвязном списке потомков. В примере выше, Child1 является файбером-потомком для Parent, а Child2 - одноуровневый элемент (sibling) для Child1.

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

`return`

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

Если у файбера есть несколько потомков, return каждого потомка ссылается на родителя. В примере выше, для Child1 и Child2 return будет ссылаться на Parent.

`pendingProps` и `memoizedProps`

Концептуально, пропсы (props) это аргументы функции. Файберу устанавливаются pendingProps в начале выполнения, а memoizedProps устанавливаются в конце.

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

`pendingWorkPriority`

Число означающее приоритет работы соответсвующего файбера. В модуле ReactPriorityLevel перечислены разные уровни приоритетов и то, что они представляют.

За исключением приоритета NoWork, равного нулю, большее число соответствует меньшему приоритету. Например, можно было бы использовать следующую функцию, чтобы проверить, что приоритет файбера выше или равен заданному:

function matchesPriority(fiber, priority) {
    return fiber.pendingWorkPriority !== 0 &&
        fiber.pendingWorkPriority <= priority
}

Планировщик использует значение приоритета, чтобы найти следующий блок работы на выполнение. Этот алгоритм рассмотрим в следующих разделах.

`alternate`, дублер

очистка файбера

Очистить файбер означает отрисовать его результат на экране.

незавершенный файбер

Необработанный файбер. Концептуально, текущий фрейм стека.

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

Дублер (alternate) данного файбера — незавершенный файбер, а дублер незавершенного файбера — данный файбер.

Дублер файбера создается отложено с помощью функции cloneFiber. Вместо того, чтобы постоянно создавать новый объект, cloneFiber попытается переиспользовать дублер, если он есть, чтобы минимизировать выделение памяти.

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

`output`, вывод

хост-компонент

Хост-компонент — листовая вершина в дереве элементов приложения. Хост-компоненты специфичны для среды отрисовки (например, в браузере это div, span и так далее). В JSX, они обозначаются с помощью тегов в нижнем регистре.

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

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

Вывод это то, что в итоге передается отрисовщику, чтобы он мог сбросить изменения в среду отрисовки. Отрисовщик определяет как вывод создается и обновляется.

Будущие разделы

Это все, что есть на данный момент, но этот документ еще далек до завершения. Будущие секции будут описывать алгоритмы используемые на протяжении жизненного цикла обновления. Темы для обсуждения включают:

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

Видео по теме

What's Next for React (ReactNext 2016)

Когда нужен React.memo?

jennypollard — Fri, 25 Nov 2022 06:33:14 +0000

Когда нужен React.memo?

Компонент обновляется (перерисовывается), когда меняется его состояние. Когда обновляется компонент, обновляются все его дочерние компоненты и рекурсивно дочерние компоненты дочерних компонентов.

Компонент может иметь глубокую вложенность дочерних компонентов:

const C = () => <div />;
const B = () => <C />
const A = () => <B />;

const App = () => {
    return <A />;
}

В примере выше, при обновлении компонента App произойдет обновление всех вложенных компонентов: A, B и C.

Обновление всех дочерних компонентов может быть нежелательно - если у компонента не меняется состояние и пропсы, то и обновлять его не надо. Обновление компонента можно остановить с помощью React.memo (мемо). Мемо создает элемент, который ссылается на мемоизируемый компонент и содержит функцию сравнения пропсов для этого компонента:

export function memo(type, compare) {
  const elementType = {
    $$typeof: REACT_MEMO_TYPE,
    type,
    compare: compare === undefined ? null : compare,
  };

  return elementType;
}

При обновлении компонентов, React распознает мемо и вызывает функцию compare чтобы определить изменились ли пропсы, если нет — можно пропустить обновление:

const prevProps = currentChild.memoizedProps;
// Default to shallow comparison
let compare = Component.compare;
compare = compare !== null ? compare : shallowEqual;
if (compare(prevProps, nextProps) && current.ref === workInProgress.ref) {
  return bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes);
}

Возвращаясь к первому примеру, обернем компонент A в мемо:

const C = () => <div />;
const B = () => <C />
const A = React.memo(() => <B />);

const App = () => {
    return <A />;
}

Теперь, при обновлении App, компонент A и его вложенные компоненты обновляться не будут, так как их пропсы не изменяются.

Использование мемо даст результат, если:

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

Credits: foto by Oskar Yildiz https://unsplash.com/photos/gy08FXeM2L4

React: сфокусировать поле ввода по чекбоксу

jennypollard — Thu, 10 Nov 2022 19:36:56 +0000

Как установить фокус на поле ввода (инпут) при изменении чекбокса?

Даны чекбокс <input type="checkbox"> и поле ввода <input type="text">. Хочу фокусировать поле ввода, когда пользователь отмечает чекбокс — так пользователю будет понятно, что от него ожидается ввод текста, если чекбокс включён.
Напишу компонент, который показывает чекбокс и поле ввода, значение для поля ввода сохраню с помощью хуков useState и useCallback:

export const App = () => {
  const [value, setValue] = useState("");
  const handleInputChange = useCallback(
    (event) => setValue(event.target.value),
    []
  );

  return (
    <main>
      <input type="checkbox" />
      <input type="text" value={value} onChange={handleInputChange} />
    </main>
  );
};

Добавлю обработчик на изменение чекбокса: покажу алерт с новым значением. Обработчик события вызывается с объектом event, в свойстве target лежит элемент, который вызвал событие, в моем случае event.target — чекбокс. Новое значение чекбокса можно получить из его свойства checked: event.target.checked:

export const App = () => {
  const [value, setValue] = useState("");
  const handleInputChange = useCallback(
    (event) => setValue(event.target.value),
    []
  );
  const handleChange = useCallback((event) => {
    alert(event.target.checked);
  }, []);

  return (
    <div className="App">
      <input type="checkbox" onChange={handleChange} />
      <input type="text" value={value} onChange={handleInputChange} />
    </div>
  );
};

Теперь, при изменении чекбокса, установлю фокус в поле ввода. У элементов, которые могут получать фокус ввода, есть метод focus. Чтобы вызвать этот метод у поля ввода, его нужно найти - в этом поможет механизм ref-ов и хук useRef.
Создам ref и передам его пропсой полю ввода:

const inputRef = useRef();
// ...
<input 
  type="text"
  value={value}
  onChange={handleInputChange}
  ref={inputRef}
/>;

React, после рендера элементов, поместит в inputRef ссылку на поле ввода. У всех ref-ов есть свойство current, в котором хранится значение ref-а. Воспользуюсь им, чтобы вызвать метод focus у элемента, для этого в обработчик изменения чекбокса добавлю inputRef.current.focus():

export const App = () => {
  const [value, setValue] = useState("");
  const inputRef = useRef();
  const handleInputChange = useCallback((e) => setValue(e.target.value), []);
  const handleChange = useCallback(
    (e) => {
      if (e.target.checked) {
        inputRef.current.focus();
      }
    },
    [inputRef]
  );
  return (
    <div className="App">
      <input type="checkbox" onChange={handleChange} />
      <input
        type="text"
        value={value}
        onChange={handleInputChange}
        ref={inputRef}
      />
    </div>
  );
};

Иногда может оказаться, что решение с использованием ref-ов слишком сложное. Тогда можно попробовать найти нужный элемент с помощью DOM API — например, document.querySelector. Чтобы найти элемент используя querySelector, его нужно как-то идентифицировать, добавлю ему id. Затем, в обработчике изменения чекбокса, заменю ref на вызов document.querySelector:

export const App = () => {
  const [value, setValue] = useState("");
  const handleInputChange = useCallback((e) => setValue(e.target.value), []);
  const handleChange = useCallback((e) => {
    if (e.target.checked) {
      document.querySelector("#input").focus();
    }
  }, []);
  return (
    <div className="App">
      <input type="checkbox" onChange={handleChange} />
      <input
        id="input"
        type="text"
        value={value}
        onChange={handleInputChange}
      />
    </div>
  );
};

Использовать documenent.querySelector нежелательно:

нет гарантии, что найдет нужный элемент — сколько еще может быть на странице элементов с таким же селектором?
компонент перестанет работать в окружении, где нет document.
querySelector будет искать элемент по всему дереву, а React сохранит ссылку на элемент в ref-е при рендере, что быстрее.

Поэтому вариант с ref-ами более стабильный и предсказуемый.