Условный рендеринг в React: методы и примеры

Условный рендеринг в React — это набор приёмов для показа разных элементов или компонентов в зависимости от состояния приложения. В статье описаны основные способы (if/else, тернарный оператор, переменные элементов, логические операторы, возвращение null), реальные примеры (загрузка API, ошибки формы) и рекомендации по выбору подхода, тестированию и доступности.

Фото кода на экране компьютера

Условный рендеринг означает изменение визуального и поведенческого вывода компонента в зависимости от его состояния или входных данных. Проще: приложение показывает разный интерфейс при разных условиях — например, «Войти» или «Выйти», индикатор загрузки или контент, сообщение об ошибке или форма ввода.

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

Зачем это нужно

Управлять отображением разных состояний (загрузка, ошибка, пустой результат, данные).
Разделять UI на мелкие переиспользуемые кусочки.
Улучшать UX: не показывать кнопки, когда они не нужны; показывать подсказки и сообщения.

Основные подходы

Ниже — практические способы реализовать условный рендеринг. Для примеров предполагается базовое знание React и хуков (useState, useEffect).

1. if / else

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

function Dashboard(props) {
  const { isLoggedIn } = props;
  if (isLoggedIn) {
    return ;
  } else {
    return ;
  }
}

Когда использовать: когда ветви существенно отличаются по структуре или содержат сложные выражения.

2. Тернарный оператор

Короткая запись для простой ветвящейся логики. Хорош для инлайн-рендеринга небольших фрагментов.

function Dashboard(props) {
  const { isLoggedIn } = props;
  return (
    <>
      {isLoggedIn ?  : }
    
  );
}

Плюсы: компактно. Минусы: при вложенных тернарных выражениях читаемость падает.

3. Переменные элементов

Можно подготовить переменную и присвоить ей JSX в зависимости от условий. Удобно, когда нужно вычислить содержимое заранее или добавить несколько условий.

function LoginBtn(props) {
  return (
    
  );
}

function LogoutBtn(props) {
  return (
    
  );
}

function Dashboard() {
  const [loggedIn, setLoggedIn] = useState(true);
  const handleLogin = () => setLoggedIn(true);
  const handleLogout = () => setLoggedIn(false);

  let button;
  if (loggedIn) {
    button = ;
  } else {
    button = ;
  }

  return (
    <>
      {button}
    
  );
}

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

4. Логические операторы (&& и ||)

Оператор && позволяет отрендерить элемент только если условие истинно. Оператор || можно использовать как запасной вариант.

function ShowNotifications(props) {
  const { notifications } = props; // ожидаем массив
  return (
    <>
      {notifications.length > 0 && (
        You have {notifications.length} notifications.
      )}
    
  );
}

С оператором || можно показать альтернативу, если первая часть ложно:

function ShowNotifications(props) {
  const { notifications } = props;
  return (
    <>
      {(notifications.length > 0 && (
        You have {notifications.length} notifications.
      )) || You have no notifications}
    
  );
}

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

5. Возврат null чтобы предотвратить рендер

Если компонент ничего не должен показывать, можно вернуть null. React ничего не отрисует.

function Warning(props) {
  const { warningMessage } = props;
  if (!warningMessage) {
    return null;
  }
  return (
    <>
      
    
  );
}

// Использование
//  // будет кнопка
//  // ничего не будет

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

Примеры из реальных приложений

Рассмотрим практические сценарии: загрузка данных с API и отображение ошибок в формах.

Загрузка данных с API

Запрос может занять время. До получения данных пытаться рендерить вложенные свойства объекта опасно — будет ошибка. Проверяйте наличие данных перед использованием.

import axios from 'axios';
import { useState, useEffect } from 'react';

function FetchData() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let mounted = true;
    const apiURL = 'https://api.nasa.gov/planetary/apod?api_key=DEMO_KEY';
    axios.get(apiURL)
      .then(response => {
        if (mounted) setData(response.data);
      })
      .catch(err => {
        if (mounted) setError(err.message || 'Ошибка запроса');
      })
      .finally(() => {
        if (mounted) setLoading(false);
      });
    return () => { mounted = false; };
  }, []);

  if (loading) return Загрузка...;
  if (error) return Ошибка: {error};

  return (
    <>
      Astronomy picture of the day
      {data && (
        <>
          {data.title}
          {data.explanation}
        
      )}
    
  );
}

Рекомендация: отдельное состояние для loading, data и error упрощает управление и тестирование.

Отображение ошибок форм

Ошибка должна показываться только когда она есть. Обновляйте состояние ошибок и рендерьте сообщения условно.

function EmailInput() {
  const [email, setEmail] = useState('');
  const [error, setError] = useState(null);

  const validate = () => {
    const valid = /\S+@\S+\.\S+/.test(email);
    setError(valid ? null : 'Неверный формат email');
    return valid;
  };

  return (
    <>
       setEmail(e.target.value)} />
      {error && {error}}
      
    
  );
}

Совет: используйте role=”alert” для сообщений об ошибке, чтобы их заметили пользователи со скрин-ридерами.

Когда какой метод выбрать — эвристики

Простая бинарная логика, короткий JSX: тернарный оператор.
Сложные ветви с большим количеством JSX: if/else или переменные элементов.
Показывать контент только при наличии данных: &&.
Полностью скрыть компонент: return null.

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

Производительность и побочные эффекты

Условный рендер сам по себе не влияет сильно на производительность. Важнее:

Не создавать тяжёлые вычисления напрямую в JSX — вынесите в useMemo или в отдельную функцию.
Избегайте частых пересозданий компонентов и анонимных функций в props при большом дереве.
Для дорогостоящих поддеревьев используйте React.memo и ленивую загрузку (React.lazy + Suspense).

Доступность и UX

Если скрываете важный контент, убедитесь, что его отсутствие ожидаемо для пользователя.
Сообщения об ошибках должны быть фокусируемыми и воспринимаемыми скрин-ридерами (role=”alert”).
При переключениях состояния предоставляйте визуальные индикаторы (загрузки, disabled-кнопки).

Тесты и приёмка

Критерии приёмки:

Компонент корректно показывает все ожидаемые состояния: загрузка, успех, пусто, ошибка.
Переходы между состояниями запускаются корректно при изменении пропсов/состояния.
Нет ошибок в консоли при пустых данных.
Сообщения об ошибках доступны для скрин-ридеров.

Минимальные тесты:

Snapshot для каждой ветки рендера.
Юнит-тест: отображается «Загрузка» при loading=true.
Юнит-тест: при data != null отображается заголовок.
Интеграционный тест: имитация клика меняет состояние кнопки Login/Logout.

Шпаргалка по синтаксису (cheat sheet)

if/else — для больших ветвей.
Тернар ? : — для коротких выборов.
&& — для показа только при true.
|| — как запасной вариант для дефолтного UI.
return null — ничего не рендерить.

Примеры альтернативных подходов

Lens-компоненты: вынесение условной логики в отдельные компоненты-контейнеры.
Pattern: State Machine (xstate) — для сложных переходов между множеством состояний.
Render props / HOC — при необходимости делиться логикой между компонентами.

Решающее дерево (decision tree)

flowchart TD
  A[Нужно ли показывать UI?] -->|Нет| B[return null]
  A -->|Да| C[Сколько вариантов?]
  C -->|2 и короткие| D[Тернар]
  C -->|Несколько или большой JSX| E[if/else или переменная]
  C -->|Показать только при наличии данных| F[&& оператор]
  D --> G[Проверить читаемость]
  E --> G
  F --> G

Риски и способы их снижения

Риск: запутанные вложенные тернарные операторы → Решение: разделить логику на функции/переменные.
Риск: непредвидённые null/undefined → Решение: проверки наличия данных, optional chaining.
Риск: пропущенная доступность → Решение: использовать aria-атрибуты и роли.

Рольовые чек-листы

Разработчик:

Разбить UI на маленькие компоненты.
Написать проверки на пустые данные.

Код-ревьюер:

Оценить читаемость ветвления.
Проверить обработку ошибок и доступность.

Тестер:

Написать тесты для всех состояний.
Проверить работу на медленных сетях.

Краткое резюме

Условный рендеринг — базовый инструмент в React. Выбор между if/else, тернарным оператором, переменными элементов и логическими операторами зависит от сложности логики и приоритетов читаемости. Всегда учитывайте доступность, тестируемость и производительность при проектировании условных веток.

Важные заметки