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

Какво е useCallback в React

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

Синтактично 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);

    // Стабилна референция — същата функция, докато deps не се променят
    const handleClick = useCallback(() => {
        setCount(prev => prev + 1);
    }, []);

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

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

Мемоизацията в useCallback се основава на кеширане на резултата от извикването на функцията. React запазва closure-а, създаден в момента на първия рендър, и го връща при следващите рендъри, докато зависимостите остават непроменени. Вътре във fiber възела всяко извикване на useCallback създава възел в свързания списък на хуковете, където се съхраняват предишните зависимости и мемоизираната стойност.

Процесът на сравняване на зависимостите се извършва строго чрез Object.is — това е повърхностно сравнение, без задълбочена проверка на обекти или масиви. Ако в зависимостите има обект или масив, новата референция при всеки рендър ще бъде считана за промяна. Затова в масива от зависимости трябва да се предават примитивни стойности или стабилни референции (например от useRef или useMemo).

Според React Core Team — Optimization Guide (2024), цената на мемоизацията включва три компонента: заделяне на масива от зависимости при всеки рендър, обхождане и сравняване на елементите чрез Object.is и потенциален overhead от garbage collection при пресъздаването. За компонент със стотици useCallback обвивки това може да стане забележимо — затова селективността при използването на хука е от решаващо значение.

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

Разпространен е митът, че useCallback автоматично подобрява производителността. В действителност, изолирано (без React.memo) useCallback дори леко забавя приложението поради цената на сравняването на зависимостите. Хукът носи реална полза само в три сценария: предотвратяване на ре-рендъри на React.memo компоненти, стабилност на callback-ите в useEffect и предаване на персонализирани хукове, които зависят от reference equality.

Правилото е просто: докато не откриеш проблем с производителността чрез React DevTools Profiler — не използвай useCallback. Екипът на React многократно е подчертавал, че преждевременната оптимизация е коренът на злото. Първо напиши чист код без мемоизация, измери, намери тясното място в профилъра и едва тогава добави useCallback там, където наистина е необходимо.

// Измерима оптимизация: Child е обвит в React.memo
const Child = React.memo(({ onClick }) => {
    console.log('Child се ре-рендърва');
    return <button onClick={onClick}>Click</button>;
});

function Parent() {
    const handleClick = useCallback(() => {
        console.log('щракнато');
    }, []);
    return <Child onClick={handleClick} />;
}

Според Dan Abramov — Before You memo() (2024), повече от 90% от случаите на използване на useCallback в open-source проекти са излишни. Разработчиците обвиват всяка функция „за всеки случай", без да измерват ефекта. Алтернатива: ако дъщерният компонент е тежък и ре-рендърът му е скъп — React.memo + useCallback са оправдани. Ако дъщерният компонент е лек — ре-рендърът е по-евтин от сравняването на зависимостите.

Кога да използваш useCallback

Първият сценарий — React.memo. Ако дъщерният компонент е обвит в React.memo и приема callback функция като prop, без useCallback дъщерният компонент ще се прерисува при всеки рендър на родителя, дори ако собствените му данни не са се променили. useCallback стабилизира референцията и React.memo може правилно да пропусне ре-рендъра.

Вторият сценарий — useEffect с callback в зависимостите. Ако функцията се предава в масива от зависимости на useEffect, всяка нова референция ще рестартира ефекта. useCallback гарантира, че референцията е стабилна, и ефектът се изпълнява само при промяна на реалните данни, а не при всеки рендър. Това е особено важно за абонаменти и заявки.

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

// useCallback за стабилна зависимост на useEffect
const fetchData = useCallback(async (id) => {
    const res = await fetch(`/api/${id}`);
    setData(res.data);
}, []); // стабилна референция, никога не се пресъздава

useEffect(() => {
    fetchData(props.id);
}, [props.id, fetchData]); // ефектът се изпълнява само при промяна на props.id

useCallback срещу 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 с функция — те генерират един и същ код.

// Тези са еквивалентни:
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.
• Обекти и масиви в зависимостите — новата референция при всеки рендър се счита за промяна, мемоизацията е безполезна.

// ❌ Безполезно: без React.memo на child
const handle = useCallback(() => doStuff(), []);
<Child onClick={handle} />; // Child пак се ре-рендърва без React.memo

// ❌ Stale closure: липсва зависимост
const handle = useCallback(() => {
    console.log(count); // count винаги е 0 — stale closure!
}, []);

// ✅ Правилно: включи зависимостите
const handle = useCallback(() => {
    console.log(count);
}, [count]);

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