Что такое хук useRef?

useRef возвращает один и тот же объект на протяжении жизни компонента. Обычно он выглядит так: { current: value }. React сохраняет этот объект между рендерами. Вы можете положить туда значение и прочитать его позже.

Главное для ответа: изменение ref.current не запускает новый render. React не считает такую мутацию изменением состояния. Поэтому ref хорош для данных, которые нужны коду, но не должны напрямую менять то, что пользователь видит на экране.

Короткая формулировка для интервью:

useRef хранит мутабельное значение между рендерами. Его current можно менять без ререндера. Поэтому ref используют для DOM-элементов и служебных данных. Если значение должно обновить UI, я выберу state, а не ref.

Самый понятный сценарий это доступ к DOM-элементу после монтирования. Например, можно поставить фокус в input по клику. Не вызывайте метод DOM во время render. Элемента еще может не быть.

import { useRef } from "react";

export function SearchBox() {
  const inputRef = useRef<HTMLInputElement | null>(null);

  function focusSearch() {
    inputRef.current?.focus();
  }

  return (
    <>
      <label htmlFor="search">Search</label>
      <input id="search" ref={inputRef} type="search" />
      <button type="button" onClick={focusSearch}>
        Focus search
      </button>
    </>
  );
}

Здесь inputRef.current сначала равен null, а после монтирования React запишет туда DOM-узел. Проверка через ?. защищает от ситуации, когда элемент условно не отрисован или уже размонтирован. У поля есть видимый label, поэтому фокус не ломает доступность для клавиатуры и скринридеров.

Второй частый сценарий это служебное значение, которое не нужно показывать в UI. Например, id таймера для debounce и AbortController для отмены старого запроса. Если хранить их в state, вы получите лишний render. Если хранить в обычной переменной, значение потеряется при следующем render.

import { useEffect, useRef } from "react";

export function Autosave({ draft }: { draft: string }) {
  const timeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null);
  const abortRef = useRef<AbortController | null>(null);

  useEffect(() => {
    if (timeoutRef.current) {
      clearTimeout(timeoutRef.current);
    }

    abortRef.current?.abort();
    const controller = new AbortController();
    abortRef.current = controller;

    timeoutRef.current = setTimeout(() => {
      void fetch("/api/draft", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ draft }),
        signal: controller.signal,
      }).catch((error) => {
        if (error instanceof DOMException && error.name === "AbortError") {
          return;
        }

        console.error("Autosave failed", error);
      });
    }, 500);

    return () => {
      if (timeoutRef.current) {
        clearTimeout(timeoutRef.current);
      }

      controller.abort();
    };
  }, [draft]);

  return null;
}

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

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

Ref на DOM-элемент заполняется после того, как React привязал узел к дереву. При размонтировании или исчезновении элемента из-за условного render значение снова может стать null. Поэтому в сильном ответе есть проверка current и правильное место для побочного действия.

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

Ref часто используют, чтобы запомнить предыдущее значение prop или state. Это не замена state, потому что предыдущее значение обычно нужно только для сравнения или эффекта, а не как самостоятельный источник UI.

import { useEffect, useRef } from "react";

export function PriceChange({ price }: { price: number }) {
  const previousPriceRef = useRef<number | null>(null);

  useEffect(() => {
    previousPriceRef.current = price;
  }, [price]);

  const previousPrice = previousPriceRef.current;

  return (
    <p>
      Current: {price}, previous: {previousPrice ?? "unknown"}
    </p>
  );
}

Здесь важно понимать порядок. Во время render вы видите значение ref из прошлого commit. После commit эффект запишет новое значение. Это нормальный паттерн, если вам нужен именно previous value. Но не превращайте его в скрытое состояние всего компонента.

Сам useRef можно вызывать при серверном рендеринге, как и другие хуки. Но DOM на сервере отсутствует. Значит, нельзя рассчитывать, что ref.current содержит DOM-узел до монтирования на клиенте.

Если вам нужно работать с window, измерять элемент, вызывать focus или подключать сторонний DOM-виджет, делайте это после монтирования. Обычно подходит обработчик события или useEffect. На SSR это снижает риск ошибки из-за отсутствия браузерного API.

Еще один нюанс: ref не проходит внутрь вашего компонента автоматически так же, как обычный prop. Если родитель должен получить доступ к внутреннему DOM-элементу, дочерний компонент должен явно поддержать это через forwardRef.

import { forwardRef } from "react";

const TextInput = forwardRef<HTMLInputElement, { label: string }>(
  function TextInput({ label }, ref) {
    return (
      <label>
        {label}
        <input ref={ref} />
      </label>
    );
  }
);

На интервью достаточно сказать, что обычный ref на DOM и ref на пользовательский компонент это не одно и то же. Для публичного imperative API есть useImperativeHandle. Применяйте его точечно, когда props не подходят.

Хороший ответ про useRef строится вокруг контракта. Ref сохраняет значение между рендерами, не вызывает render при изменении и подходит для мутабельных служебных данных. Это делает его полезным. Но ref опасен, если использовать его как скрытый state.

Если хотите звучать сильнее, добавьте границы. ref.current может быть null. DOM доступен только после монтирования. Мутации ref не отслеживаются зависимостями useEffect. Ресурсы в ref требуют cleanup. Такой ответ показывает не только знание API, но и понимание багов из реального frontend-кода.