Как использовать принципы SOLID в React-разработке

Что проверяют

Можете ли вы перенести принципы из мира классов в мир функций и композиции, а не пересказать определения. Хороший знак, когда кандидат сам говорит, где принцип в React выглядит иначе. Следом часто просят показать это на компоненте из вашего проекта.

Как отвечать

Пройдите по принципам и для каждого назовите React-идиому:

• SRP: компонент отвечает за отображение, а загрузка данных, подписки и бизнес-правила уходят в кастомные хуки (useUser, useCart). Сигнал нарушения: компонент на 400 строк с пятью useEffect;
• OCP: расширение через композицию, children, слоты и render props. Если под каждый новый случай в Card добавляется булев проп isCompact, withIcon, hideFooter, компонент открыт для модификации, а не для расширения;
• LSP: наследование компонентов в React не используется, поэтому принцип читается как соблюдение контракта. Ваша Button поверх нативной кнопки принимает ComponentProps<'button'>, прокидывает ...rest и ref и ведёт себя как <button>: disabled, type, onClick работают так, как ожидает вызывающий код;
• ISP: узкие props. Аватару нужны name и src, а не весь объект user с тридцатью полями. Заодно это сокращает лишние перерисовки;
• DIP: компонент зависит от абстракции, а не от конкретного fetch или SDK. Зависимость приходит через проп или контекст, в тестах провайдер подменяется заглушкой. Контекст здесь работает как механизм внедрения зависимостей.

Завершите тем, что SOLID в React это ориентир для границ ответственности и тестируемости, а не набор правил, который нужно выполнять в каждом файле.

Где спотыкаются

Переносят примеры из Java буквально: PrimaryButton extends Button. Наследование компонентов React не рекомендует, вариации делаются через props и композицию, и такой пример сразу выдаёт, что вы React не практиковали.

Дробят всё до атомов ради SRP. Двадцать файлов по десять строк читать тяжелее, чем один понятный компонент, а связи между ними становятся неявными.

Путают DIP с «положим всё в глобальный стор». Стор сам превращается в конкретную зависимость, от которой компонент не отвязать в тестах.