> До какого размера стоит делать React компоненты (React)

Короткий ответ

React компоненты стоит делать достаточно маленькими, чтобы каждый решал одну задачу (single responsibility). Практический ориентир - 50-100 строк кода, 1-2 уровня вложенности JSX, не более 3-5 пропсов. Компонент не должен требовать скролла для полного просмотра. Если появляется сложная логика, несколько useState или useEffect - пора декомпозировать.

Подробное объяснение

Размер компонента - это trade-off между читаемостью, переиспользуемостью и производительностью. Маленькие компоненты (10-30 строк) легче тестировать и переиспользовать, но их избыток усложняет навигацию. Большие компоненты (200+ строк) быстрее писать, но они становятся "божественными объектами" - сложно поддерживать, тестировать и изменять.

Ключевые критерии для декомпозиции:

• Логическая связанность: если часть JSX имеет свою state-логику или обработчики - выносить.
• Повторяемость: одинаковые блоки UI (карточки, строки таблицы) - отдельный компонент.
• Уровень абстракции: компонент не должен смешивать бизнес-логику и детали рендеринга (например, data-fetching внутри презентационного компонента).
• Тестируемость: если для теста нужно мокать 5 зависимостей - компонент слишком большой.

Оптимальная структура: контейнер (логика, стейт, эффекты) + несколько презентационных компонентов (только props, без логики). Контейнер может быть 100-150 строк, презентационные - 20-50.

На практике

Для senior-уровня важно не механическое дробление, а осмысленная архитектура. Правило "один компонент - одна ответственность" работает, но с поправкой на контекст: в крупном проекте компонент может быть больше, если он инкапсулирует сложную, но целостную функциональность (например, кастомный календарь).

Практические признаки, что компонент пора делить:

• JSX занимает больше 80 строк;
• больше 5 пропсов (особенно boolean-флагов);
• больше 3 useState или 2 useEffect;
• есть вложенные тернарники или условный рендеринг с 3+ ветками;
• компонент принимает children и сам управляет их layout.

Хорошая практика - использовать композицию: выносить не только UI-куски, но и логические хуки (custom hooks), которые можно переиспользовать между компонентами.

Пример кода

Плохо (один большой компонент):

TSX
const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState([]);
  const [isEditing, setIsEditing] = useState(false);

  useEffect(() => { /* fetch user */ }, []);
  useEffect(() => { /* fetch posts */ }, [user]);

  return (
    <div>
      <div className="header">{user?.name}</div>
      <div className="avatar"><img src={user?.avatar} /></div>
      <div className="bio">{user?.bio}</div>
      {isEditing && <EditForm user={user} onSave={...} />}
      <div className="posts">
        {posts.map(post => (
          <div key={post.id}>
            <h3>{post.title}</h3>
            <p>{post.body}</p>
          </div>
        ))}
      </div>
    </div>
  );
};

Хорошо (декомпозиция):

TSX
const UserProfile = () => {
  const { user, isLoading } = useUser();
  const { posts } = useUserPosts(user?.id);

  return (
    <div>
      <UserHeader user={user} />
      <UserBio bio={user?.bio} />
      <UserPosts posts={posts} />
    </div>
  );
};

const UserHeader = ({ user }) => (
  <div className="header">
    <Avatar src={user?.avatar} />
    <UserName name={user?.name} />
  </div>
);

Как отвечать на собеседовании

Начни с чёткого тезиса: "размер компонента определяется не строками, а ответственностью". Приведи конкретные метрики (50-100 строк, 3-5 пропсов), но подчеркни, что это ориентиры, а не жёсткие правила. Объясни trade-off: маленькие компоненты - больше файлов и сложнее навигация, большие - сложнее тестировать.

Покажи понимание композиции и разделения на container/presentational. Упомяни custom hooks как способ выноса логики без создания новых компонентов. Если спросят про производительность - скажи, что размер компонента редко влияет на re-renders, важнее правильное использование React.memo и useMemo.

Что проверяет интервьюер

• Понимание принципов SOLID (особенно single responsibility) в контексте React.
• Умение балансировать между читаемостью и производительностью.
• Опыт рефакторинга и декомпозиции реальных проектов.
• Знание паттернов (container/presentational, compound components, render props).
• Способность аргументировать решения, а не следовать догмам.

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

• Дробление до абсурда: компонент из 5 строк с одним пропсом - избыточно.
• Смешивание логики и представления: data-fetching внутри презентационного компонента.
• Игнорирование контекста: в маленьком проекте можно иметь компоненты побольше, в большом - строже декомпозиция.
• Отсутствие композиции: передача 10 пропсов вместо использования children или render props.
• Преждевременная оптимизация: деление компонентов "на всякий случай" без реальной необходимости.