useCallback — ключевые понятия, хук мемоизации функций в React

Что такое useCallback в React

useCallback — это хук, добавленный в React 16.8, который мемоизирует функцию: возвращает одну и ту же ссылку до тех пор, пока зависимости не изменятся. Без useCallback каждое объявление функции внутри компонента создаёт новый объект функции при каждом рендере. Для примитивов это незаметно, но при передаче таких callback-ов в дочерние компоненты, оптимизированные через React.memo, каждый новый reference вызывает ререндер дочернего компонента.

Синтаксически useCallback эквивалентен useMemo для функции: useCallback(fn, deps) — это сокращение для useMemo(() => fn, deps). React хранит мемоизированную функцию во внутреннем хранилище fiber-узла и сравнивает зависимости при каждом рендере. Если зависимости не изменились (Object.is для каждого элемента), возвращается предыдущая функция.

По данным React Documentation — useCallback (2025), не стоит оборачивать каждую функцию в useCallback. Хук имеет свою цену: вызов хука, сравнение зависимостей и аллокация памяти под массив зависимостей. Если компонент простой и не имеет глубоких деревьев с React.memo — useCallback будет только замедлять приложение. Оптимизация должна быть измеримой, а не интуитивной.

import { useCallback } from 'react';

function Parent() {
    const [count, setCount] = useState(0);

    // Stable reference — same function until deps change
    const handleClick = useCallback(() => {
        setCount(prev => prev + 1);
    }, []);

    return <Child onClick={handleClick} />;
}

Как работает мемоизация функций

Мемоизация в useCallback основана на кэшировании результата вызова функции. React сохраняет замыкание, созданное в момент первого рендера, и возвращает его при последующих рендерах, пока зависимости остаются неизменными. Внутри fiber-узла каждый вызов useCallback создаёт узел в связном списке хуков, где хранятся предыдущие зависимости и мемоизированное значение.

Процесс сравнения зависимостей выполняется строго через Object.is — это поверхностное сравнение, без глубокой проверки объектов или массивов. Если в зависимостях объект или массив, новая ссылка при каждом рендере будет считаться изменением. Поэтому в массиве зависимостей нужно передавать примитивные значения или стабильные ссылки (например, из useRef или useMemo).

По данным React Core Team — Optimization Guide (2024), стоимость мемоизации включает три компонента: аллокацию массива зависимостей на каждый рендер, обход и сравнение элементов через Object.is и потенциальный overhead от сборки мусора при пересоздании. Для компонента с сотнями useCallback-обёрток это может стать заметным — поэтому селективность в использовании хука критична.

useCallback и производительность

Широко распространён миф, что useCallback автоматически улучшает производительность. На самом деле, в изоляции (без React.memo) useCallback даже немного замедляет приложение из-за cost сравнения зависимостей. Реальную пользу хук приносит только в трёх сценариях: предотвращение ререндеров React.memo-компонентов, стабильность callback-ов в useEffect и передача в кастомные хуки, которые зависят от reference equality.

Правило простое: пока не обнаружишь проблему с производительностью через React DevTools Profiler — не используй useCallback. React-команда неоднократно подчёркивала, что предварительная оптимизация — корень зла. Сначала напиши чистый код без мемоизации, измерь, найди bottleneck в профилировщике и только потом добавляй useCallback там, где действительно нужно.

// Measurable optimization: Child is wrapped in React.memo
const Child = React.memo(({ onClick }) => {
    console.log('Child re-rendered');
    return <button onClick={onClick}>Click</button>;
});

function Parent() {
    const handleClick = useCallback(() => {
        console.log('clicked');
    }, []);
    return <Child onClick={handleClick} />;
}

По данным Dan Abramov — Before You memo() (2024), более 90% случаев использования useCallback в open-source проектах — избыточны. Разработчики оборачивают каждую функцию «на всякий случай», не измеряя эффект. Альтернатива: если дочерний компонент тяжёлый и его ререндер дорог — React.memo + useCallback оправданы. Если дочерний компонент лёгкий — ререндер дешевле, чем сравнение зависимостей.

Когда использовать useCallback

Первый сценарий — React.memo. Если дочерний компонент обёрнут в React.memo и принимает callback-функцию как проп, без useCallback дочерний компонент будет перерисовываться при каждом рендере родителя, даже если его собственные данные не изменились. useCallback стабилизирует ссылку, и React.memo сможет корректно пропустить ререндер.

Второй сценарий — useEffect с callback в зависимостях. Если функция передаётся в массив зависимостей useEffect, каждая новая ссылка будет перезапускать эффект. useCallback гарантирует, что ссылка стабильна, и эффект выполняется только при изменении реальных данных, а не при каждом рендере. Это особенно важно для подписок и запросов.

• React.memo children — предотвращает ререндер мемоизированных дочерних компонентов при передаче callback-ов.
• useEffect dependencies — стабилизирует функцию в массиве зависимостей эффекта, предотвращая лишние перезапуски.
• Кастомные хуки — если хук принимает коллбэк и зависит от его reference equality, useCallback обязателен.
• Context value — если в value контекста передаётся функция, useMemo с useCallback стабилизирует ссылку.

// useCallback for stable useEffect dependency
const fetchData = useCallback(async (id) => {
    const res = await fetch(`/api/${id}`);
    setData(res.data);
}, []); // stable reference, never re-creates

useEffect(() => {
    fetchData(props.id);
}, [props.id, fetchData]); // effect runs only when props.id changes

useCallback vs useMemo

Главное различие между useCallback и useMemo в том, что мемоизирует каждый из них. useCallback мемоизирует функцию: useCallback(fn, deps) возвращает fn (ту же самую или предыдущую версию). useMemo мемоизирует результат вызова функции: useMemo(() => computeExpensive(a, b), [a, b]) возвращает вычисленное значение, а не функцию.

Технически useCallback — это синтаксический сахар над useMemo: useCallback(fn, deps) эквивалентен useMemo(() => fn, deps). Этот синтаксис существует только для читаемости — чтобы разработчик явно видел, что мемоизируется именно функция, а не значение. Разницы в производительности между useCallback и useMemo с функцией нет — они генерируют одинаковый код.

// These are equivalent:
const handleClick = useCallback(() => doSomething(a, b), [a, b]);
const handleClick = useMemo(() => () => doSomething(a, b), [a, b]);

Типичные ошибки с useCallback

Самая распространённая ошибка — бессмысленное оборачивание всех функций в useCallback без React.memo на дочерних компонентах. Если дочерний компонент не обёрнут в React.memo, он всё равно будет ререндериться при каждом рендере родителя, независимо от того, меняется ссылка на callback или нет. useCallback без React.memo — это затраты без выгоды.

• useCallback без React.memo — дочерний компонент всё равно ререндерится; оптимизация бессмысленна.
• Забытые зависимости — если внутри callback используется переменная, не указанная в deps, callback содержит stale closure.
• Избыточная мемоизация — оборачивание каждой функции, включая тривиальные onClick с console.log.
• Объекты и массивы в зависимостях — новая ссылка при каждом рендере считается изменением, мемоизация бесполезна.

// ❌ Useless: no React.memo on child
const handle = useCallback(() => doStuff(), []);
<Child onClick={handle} />; // Child still re-renders without React.memo

// ❌ Stale closure: missing dependency
const handle = useCallback(() => {
    console.log(count); // count is always 0 — stale closure!
}, []);

// ✅ Correct: include dependencies
const handle = useCallback(() => {
    console.log(count);
}, [count]);

Проблема stale closure в useCallback решается указанием всех используемых переменных в массиве зависимостей. eslint-plugin-react-hooks с exhaustive-deps автоматически проверяет, что все переменные из тела callback-а присутствуют в массиве. Если callback использует setState, который не меняется между рендерами, можно безопасно указать его в deps — React гарантирует стабильность setState.