Ответ
- Композиция компонентов - разбиение на мелкие независимые части, которые можно комбинировать (как Lego). Пример: кнопка с иконкой и текстом.
<Button>
<Icon name="user" />
<Text>Login</Text>
</Button>- Props-контроль - компонент должен быть гибким через пропсы (children, className, стили). Пример:
function Card({ children, className }) {
return <div className={`card ${className}`}>{children}</div>
}- Render Props/HOC - для логического переиспользования. Пример:
<DataFetcher render={(data) => <List items={data} />} />-
Compound Components - связанные компоненты, разделяющие состояние (например, Tabs).
-
Custom Hooks - вынос общей логики в хуки.
-
Контекст - для передачи данных без пропс-дриллинга.
-
Дизайн-система - единые правила стилей, API и документации.
Главное - компонент должен делать одну вещь, быть предсказуемым и документированным.
Ответ 18+ 🔞
Да ты послушай, что за модуль пошёл — компоненты плодить, как кролики! Ну ладно, разберёмся, как их делать, чтобы не получилось говна в стиле "один раз написал и сам через месяц не разберусь".
Первое, композиция, мать её. Это когда ты берёшь мелкие, тупые как пробка, куски и склеиваешь их, будто конструктор. Типа вот кнопка: иконка, текст, и всё это в обёртке. Чисто, понятно, и не надо городить овердохуища пропсов.
<Button>
<Icon name="user" />
<Text>Login</Text>
</Button>Второе — пропсы, ёпта. Твой компонент должен гнуться, как гимнастка, а не стоять колом. Пусть принимает children, className, любые стили — будь добр, предугадай, что захочет ебануть в него следующий разработчик.
function Card({ children, className }) {
return <div className={`card ${className}`}>{children}</div>
}Третье — рендер-пропсы и HOC'и. Это для тех случаев, когда логику надо переиспользовать, а копипастить — себя не уважать. Кинул функцию, получил данные, отрендерил что надо. Делов-то.
<DataFetcher render={(data) => <List items={data} />} />Четвёртое — compound components. Это когда у тебя есть, например, вкладки (Tabs, Tab, TabPanel). Они друг друга знают, состояние между ними шарится, но выглядят и используются как отдельные сущности. Красота, а не хуйня.
Пятое — кастомные хуки. Выноси всю свою грязную логику (запросы, таймеры, подписки) в отдельные хуки. Компонент должен быть тупым, как валенок, и отвечать только за вёрстку. Всё остальное — на сторону.
Шестое — контекст. Ну это когда уже задолбался прокидывать пропсы через десять уровней вглубь, через компоненты, которым на них насрать. Кинул в контекст — и все нижележащие могут достучаться. Но без фанатизма, а то получится глобальная помойка.
Седьмое — дизайн-система. Это чтобы все твои компоненты выглядели как родные, а не как солянка из трёх разных проектов. Единые правила для стилей, API и, блядь, документации! Чтобы не было как обычно: "А че это за пропс isDisabled? А, это disabled...".
И главное, запомни, как "Отче наш": компонент должен делать одну вещь, быть предсказуемым, как удар током от оголённого провода, и быть задокументированным. Иначе через полгода ты сам на свой же код посмотришь и скажешь: "Какой пидарас это писал?"... А потом вспомнишь, что это был ты.