Что такое HOC в React

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

На интервью важно сказать именно так: функция, которая возвращает компонент. Если назвать HOC просто компонентом внутри компонента, смысл паттерна теряется. HOC работает на уровне композиции компонентов, а не только на уровне JSX-разметки.

function withAuth<P>(WrappedComponent: React.ComponentType<P>) {
  function WithAuth(props: P) {
    const { user, loading, error } = useCurrentUser();

    if (loading) {
      return <StatusMessage role="status">Проверяем доступ...</StatusMessage>;
    }

    if (error) {
      return <AccessError retryLabel="Повторить" />;
    }

    if (!user) {
      return <LoginRequired />;
    }

    return <WrappedComponent {...props} />;
  }

  WithAuth.displayName = `withAuth(${WrappedComponent.displayName || WrappedComponent.name || "Component"})`;

  return WithAuth;
}

const ProtectedProfile = withAuth(Profile);

В этом примере Profile не меняется. Обертка решает, можно ли показать профиль, и дальше передает компоненту его исходные props. Если проверка доступа ходит в сеть, ее хук должен отменять устаревший запрос или игнорировать результат после unmount. Иначе можно получить race condition, лишний запрос и обновление состояния уже закрытого экрана.

Хороший ответ может звучать так:

HOC в React это функция, которая принимает компонент и возвращает новый компонент с дополнительной логикой. Он полезен для переиспользования сквозного поведения: авторизация, логирование, подписка на данные, feature flags. При этом HOC не должен мутировать исходный компонент, должен аккуратно прокидывать props, а создавать его внутри рендера опасно. Так можно получить remount и сброс состояния.

Если хотите добавить современный контекст, продолжите так:

Сейчас для новой логики в функциональных компонентах я чаще выберу кастомный хук. Но HOC все еще уместен, когда нужен внешний wrapper, библиотечный API или поддержка классовых компонентов.

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

Если HOC управляет видимым состоянием, он обязан быть аккуратным к UX. Проверка доступа не должна мигать приватным экраном. Загрузка не должна выглядеть как пустая страница. Ошибка сети должна иметь понятное сообщение и действие для повтора.

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

Первая ловушка: создание HOC во время рендера. Плохой пример:

function Page() {
  const ProtectedProfile = withAuth(Profile); // плохо: новый компонент может создаваться при каждом рендере

  return <ProtectedProfile userId="42" />;
}

Так делать не стоит. Если withAuth(Profile) возвращает новый компонент, React может воспринимать его как новый тип на каждом рендере. Последствие: размонтирование, потеря локального состояния, повторные запросы и лишние эффекты.

Безопаснее определить обертку вне рендера:

const ProtectedProfile = withAuth(Profile);

function Page() {
  return <ProtectedProfile userId="42" />;
}

HOC почти всегда работает с props, поэтому важно не перезаписывать данные родителя случайно. Если обертка добавляет isLoading, user или disabled, эти имена могут совпасть с тем, что уже передает внешний код. Тогда компонент получает не то значение, и баг выглядит как странное поведение UI.

Отдельная ловушка связана с ref. Он не передается как обычный prop, поэтому простого {...props} недостаточно. Если потребителю нужен ref на обернутый компонент, используйте React.forwardRef.

function withFocusRing<P>(WrappedComponent: React.ComponentType<P & React.RefAttributes<HTMLInputElement>>) {
  const WithFocusRing = React.forwardRef<HTMLInputElement, P>((props, ref) => {
    return (
      <div className="focus-ring">
        <WrappedComponent {...props} ref={ref} />
      </div>
    );
  });

  WithFocusRing.displayName = `withFocusRing(${WrappedComponent.displayName || WrappedComponent.name || "Component"})`;

  return WithFocusRing;
}

Еще один практический плюс: задавайте displayName. Без него в React DevTools легко получить цепочку безымянных оберток и потратить больше времени на поиск источника бага.

На интервью не стоит говорить, что HOC полностью устарел. Лучше показать разницу по задаче.

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

HOC возвращает новый компонент. Это удобно, когда вы хотите дать готовую обертку: withAuth(Page), withFeatureFlag(Button), connect(Component). Такой API может быть полезен в библиотеке или старом коде, где есть классовые компоненты.

Риск HOC в том, что несколько оберток подряд ухудшают читаемость. Риск хуков в том, что их нельзя вызвать из классового компонента и нельзя вызвать условно. Поэтому сильный ответ не выбирает один паттерн навсегда, а объясняет trade-off.

В Next.js отдельный риск связан с серверным рендером. Плохой пример: HOC читает window.localStorage прямо во время рендера, чтобы понять, есть ли токен. На сервере window нет, поэтому код может упасть. Даже если страница рендерится только на клиенте, первый HTML и состояние после hydration могут отличаться.

function withClientToken<P>(WrappedComponent: React.ComponentType<P>) {
  return function WithClientToken(props: P) {
    const token = window.localStorage.getItem("token"); // плохо для SSR и небезопасно при XSS

    if (!token) {
      return <LoginRequired />;
    }

    return <WrappedComponent {...props} token={token} />;
  };
}

Что сломается: SSR может получить ошибку, пользователь увидит мигание страницы входа, а токен в localStorage доступен любому XSS-скрипту. Безопаснее не читать browser-only API во время серверного рендера. Для сессии лучше использовать серверную проверку или cookie с защитой, если это подходит архитектуре. Если данные доступны только в браузере, читайте их в клиентском эффекте, показывайте loading и не рендерьте разные версии UI до завершения проверки.

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

Минимальный план ответа:

1. HOC это функция Component => NewComponent.
2. Он нужен для переиспользования сквозной логики без изменения исходного компонента.
3. Пример: авторизация, аналитика, подписка, feature flag.
4. Риски: prop collision, ref, вложенность, remount при создании в рендере.
5. В новом коде часто сравниваю с кастомным хуком и выбираю по задаче.

Если вы скажете это за 40-60 секунд и добавите один пример, ответ будет выглядеть практичным.