Композиция вместо наследования

В React нет наследования компонентов — примитив переиспользования это композиция, а не подклассы. Нет способа extend-нуть компонент и переопределить его рендер. Что React даёт взамен: компонент может отрендерить другой компонент, передать ему пропсы и передать children. «Специализация» поэтому означает «компонент, который рендерит базовый с уже сделанными выборами». Это не ограничение, которое ты обходишь; это сама модель.

type ButtonProps = React.ComponentProps<"button"> & {
  variant?: "primary" | "secondary" | "ghost";
};

function Button({ variant = "secondary", className = "", ...rest }: ButtonProps) {
  return <button className={`btn btn--${variant} ${className}`} {...rest} />;
}

Button — это база. Всё специализированное ниже будет рендерить его, а не расширять.

Специализируй, предустанавливая пропсы и пробрасывая остальное, — это весь паттерн. PrimaryButton — это просто Button с уже выбранным variant. Ты пробрасываешь children и оставшиеся пропсы, чтобы специализированный компонент оставался drop-in-заменой базы.

function PrimaryButton(props: ButtonProps) {
  // предустанавливаем один проп, пробрасываем всё остальное (children, onClick, type, ...)
  return <Button variant="primary" {...props} />;
}

// использование идентично обычному Button — children проходят насквозь нетронутыми
<PrimaryButton onClick={save}>Save changes</PrimaryButton>;

Заметь, что покупает тебе {...props}: каждый проп, который принимает Button, PrimaryButton принимает бесплатно, без списка для поддержки. Если завтра Button обзаведётся пропом disabled или aria-label, PrimaryButton уже пробрасывает его. Это композиция делает работу, которую наследование лишь притворяется, что делает, — минус хрупкая связанность с базовым классом.

children — это слот композиции, через него содержимое базы поставляется снаружи. IconButton не переопределяет, как Button рендерит; он рендерит Button, чьи children он скомпоновал. База никогда не знает и не заботится, какое содержимое получила.

function IconButton({ icon, children, ...rest }: ButtonProps & { icon: React.ReactNode }) {
  return (
    <Button {...rest}>
      <span className="btn__icon" aria-hidden>{icon}</span>
      {children}
    </Button>
  );
}

<IconButton icon={<TrashIcon />} variant="ghost" onClick={remove}>Delete</IconButton>;

IconButton компонует в слот children у Button. Button отрендерил {children} (через спред ...rest, доходящий до нижележащего <button>); IconButton решил, какими будут эти children. Ни один метод базы не был переопределён — содержимое было передано внутрь. «Передай содержимое через children» заменяет «переопредели метод рендеринга».

Ментальный тест уровня senior: спроси «использует/содержит ли X — Y?» (композиция), прежде чем «является ли X — Y?» (наследование). Формулировка отношения как содержит/использует почти всегда даёт React-ответ и держит связанность низкой — специализированный компонент зависит только от публичных пропсов Button, а не от его внутренностей, поэтому не может сломаться при смене реализации Button. Наследование привязывает подкласс к защищённой поверхности родителя; композиция привязывает обёртку только к публичному контракту пропсов.

// мышление «является» → хочет расширять (нет React API для этого, и связало бы туго)
// мышление «использует» → рендерит Button с предустановками (React-ответ, слабая связанность)
function DangerButton(props: ButtonProps) {
  return <Button variant="ghost" className="btn--danger" {...props} />;
}

Композиция почти всегда правильный ответ в React именно потому, что зависимость так тонка: обёртку, которая лишь читает пропсы Button, гораздо проще понять и менять, чем приваренную к его нутру.