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

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

Принципы SOLID применимы в React через разделение ответственности компонентов (Single Responsibility), композицию вместо наследования (Open/Closed), явные пропсы и типы (Liskov Substitution), узкие интерфейсы пропсов (Interface Segregation) и инверсию зависимостей через хуки, контекст и DI-контейнеры. Это улучшает тестируемость, переиспользование и поддерживаемость кода.

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

Single Responsibility Principle (SRP) - каждый компонент отвечает за одну задачу. Например, компонент не должен одновременно управлять данными, рендерить UI и обрабатывать анимации. Выносим логику в хуки, а UI - в презентационные компоненты.

Open/Closed Principle (OCP) - компоненты открыты для расширения, но закрыты для модификации. Используем композицию, render props, children или HOC вместо изменения существующего кода. Например, базовый компонент Button расширяется через пропсы или обёртки.

Liskov Substitution Principle (LSP) - подтипы должны заменять базовые типы без нарушения работы. В React это означает, что компонент, ожидающий определённые пропсы, должен корректно работать с любым их вариантом, соответствующим интерфейсу. Типизация через TypeScript и PropTypes помогает соблюдать LSP.

Interface Segregation Principle (ISP) - не заставляйте компонент принимать пропсы, которые он не использует. Разделяйте большие интерфейсы на мелкие, специфичные. Например, вместо одного пропса config с десятком полей используйте отдельные пропсы или группируйте их по смыслу.

Dependency Inversion Principle (DIP) - высокоуровневые модули не должны зависеть от низкоуровневых; оба должны зависеть от абстракций. В React это реализуется через инверсию зависимостей: передача сервисов через контекст, DI-контейнеры (например, InversifyJS) или хуки, которые инкапсулируют доступ к API, хранилищу и т.д.

На практике

• SRP: выносим логику запросов в кастомные хуки (useFetchUsers), а UI - в UsersList.
• OCP: создаём Modal с пропсом renderContent, чтобы расширять содержимое без изменения компонента.
• LSP: используем TypeScript с union types для пропсов, чтобы гарантировать, что замена компонента не сломает интерфейс.
• ISP: разбиваем пропсы компонента UserProfile на userData, onEdit, onDelete вместо одного объекта с неиспользуемыми полями.
• DIP: создаём абстракцию IAuthService, реализуем её в AuthApi, и передаём через React Context, чтобы компоненты не зависели от конкретной реализации.

Пример кода

TSX
// SRP: разделение ответственности
const useUserData = (id: string) => {
  const [user, setUser] = useState(null);
  useEffect(() => { fetchUser(id).then(setUser); }, [id]);
  return user;
};

const UserCard = ({ user }: { user: User }) => (
  <div>{user.name} - {user.email}</div>
);

// OCP: расширение через композицию
const Button = ({ children, ...props }) => <button {...props}>{children}</button>;
const IconButton = ({ icon, children, ...props }) => (
  <Button {...props}><Icon name={icon} />{children}</Button>
);

// ISP: узкие интерфейсы
interface UserDataProps { name: string; email: string; }
interface UserActionsProps { onEdit: () => void; onDelete: () => void; }
const UserProfile = (props: UserDataProps & UserActionsProps) => { ... };

// DIP: инверсия через контекст
const AuthContext = createContext<IAuthService>(null!);
const LoginForm = () => {
  const auth = useContext(AuthContext);
  return <button onClick={() => auth.login()}>Login</button>;
};

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

Начни с краткого определения SOLID и его ценности в React. Затем по каждому принципу приведи конкретный пример из практики: как ты решал проблему дублирования кода (SRP), как делал компонент расширяемым (OCP), как типизация помогла избежать багов (LSP), как избавился от "prop drilling" (ISP) и как вынес зависимости в контекст (DIP). Подчеркни, что SOLID - это не догма, а инструмент для борьбы с сложностью, и его применение должно быть оправдано размером проекта.

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

• Понимание не только теории SOLID, но и её практического применения в контексте React.
• Умение видеть нарушения принципов в реальном коде и предлагать рефакторинг.
• Знание композиции, хуков, контекста и TypeScript как средств реализации SOLID.
• Способность объяснять trade-offs: например, избыточная декомпозиция может усложнить код.

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

• Путать SRP с "один компонент - один файл", не видя логического разделения.
• Считать, что OCP - это только наследование, игнорируя композицию.
• Нарушать LSP, передавая в компонент пропсы, которые он не ожидает (например, лишние атрибуты в DOM).
• Создавать огромные интерфейсы пропсов, нарушая ISP.
• Жёстко связывать компоненты с конкретными реализациями API или хранилища, игнорируя DIP.