Как удобно создавать UI компоненты со множеством вариантов
Вставка
- Опубліковано 28 вер 2024
- Разбираемся с библиотекой cva - удобной абстракцией для создания многовариантных UI компонентов во фронтенд-разработке. Cva станет отличной альтернативой библиотекам classnames и clsx, которые сегодня присутствуют на множестве проектов. Кроме того, подход cva сегодня всё чаще используют популярные UI библиотеки.
Код из видео github.com/mic...
Сайт инструмента cva.style
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru...
paypal.me/mish...
Михаил, может сделаете видео по работе с Profiler в Devtools? Хотелось бы даже разбор какого-нибудь проекта небольшого с проверкой через profiler и оптимизацией
ну и желательно +- с нормальным функционалом, чтоб не просто сразу 1 функция отображалась, а как найти что-то в этом дереве, как найти нужный компонент и т.д
Не глядя лайк, затем глядеть😁
не "затем" а "зачем")
полезно спасибо
популярнейшая библиотека состощая из одной функции!
Их там две на самом деле)) Вторая - идет как алиас для clsx, чтобы две библиотеки не ставить.
А так в этом нет ничего удивительного - немало библиотек, которые предлагают только одну функцию - те же classnames и clsx были из этой же серии и активно используются.
Если на проекте используются css модули, то использование этой библиотеки даст лишь лишний написанный бойлерплейт, потому что по сути это будет маппинг css классов. В случае же если используется tailwind, то возможно такой подход сделает некоторые вещи проще, но не понятно как будет работать сам tailwind и его умная автоматизация, которая оставляет в бандле только использованные стили (вероятно никак).
Насколько понимаю, проблем с магией самого tailwind быть не должно. Я узнал об этом инструменте от Стива Кинни, который свои проекты делает на tailwind последние несколько лет.
Для css модулей мне лично нравится такой бойлерплейт, он более наглядный. Да и на практике для конкретного варианта может понадобиться более одного класса. Но выбирать всегда команде конкретного проекта.
Спасибо!
В чем преимущество использования этой библиотеки по сравнению с прокидыванием пропсов через data-атрибуты и стилизацией в CSS-модулях?
Ух. В последний раз я видел подход data-атрибутов для задания вариативности компонентов лет пять назад =) Мы использовали это на проекте с ванильным JS (без фреймворка) и тогда это было оправдано.
В целом, для меня выглядит сомнительным вариант использования data-атрибутов при работе с современными фреймворками - ведь есть обычные пропсы. И всё что нам нужно сделать на основании пропсов - это сгенерировать правильную строку с css-классами. Навешивать на элемент дополнительные html атрибуты уже не хочется.
Михаил, ну не понимаю я зачем столько движений, это же всё делается просто стилями.
Так это в итоге и делается стилями. Вопрос какие именно стили попадут на компонент, как мы будем собирать нужную строку с набором стилей. Плюс тут еще вопрос удобства типизации.
Скорость разработки уменьшает, меньше кода писать: меньше кода, меньше вероятность ошибок, меньше отладок, проще рефакториг. Бизнес скажет спасибо)
Спасибо! Для общего кругозора интересно. Но cva не заменил мне использование старого доброго import cn from 'classnames' с возможностью передачи css классов в зависимости от значения пропсов.
tailwind-variants мне показался более крутым если используете tailwind
import styles from './styles.module.scss';
const sizes = {
s: styles.sizeS,
m: styles.sizeM,
};
export type ComponentProps = {
size?: keyof typeof sizes;
}
export const Component = ({
size = 's',
}: ComponentProps ) => {
return (
);
}
И все, и так со всеми вариациями. Зачем столько бойлерплейта для этого?
жалко только что нет слотов как в tailwind-variants, с таким подходом будет проблематично строить компаунд компоненты с вариантами
Это удобно + прикольно, если ты не использует tailwind, спасибо за контент
а в чем именно неудобство использования данного подхода с tailwind? к примеру shadcn ui как раз использует сva + tailwind, можно посмотреть тот же Button
Cva - хорошая штука,но не умеет в глубь.. когда дизайн заставляет комбинировать не комбинируемые свойсвва и типизацию ломает не только в storybook а везде впринципе после сборки.
Спасибо за ваши видео) Они очень интересные. Хотелось бы продолжить тему создания компонентов, а именно - их архитектуру. Очень интересно как правильно создавать компоненты, куда их ложить по всем правилам SOLID. Знаю, что у вас есть подобные видео но очень не хватает полной картины как это все сделать в реальном проекте. Основные вопросы:
1. Нужно ли компоненты отделять от стилизации (безглавые компоненты), если да, то как.
2. Как отделить UI компоненты от инфраструктурных и куда их положить.
3. Могут ли UI компоненты иметь состояние или они должны быть только в инфраструктуре.
4. Как делать разметку (layout) используя UI компоненты и инфраструктурные.
5. Когда использовать пропсы, а когда лучше children? Например PostCard может иметь пропс title и description, а можно и вовсе сделать отдельные компоненты PostTitle, PostDescription и использовать их как children у PostCard. Но когда и какой выбирать вариант не очень понимаю)
Спасибо)
FSD посмотри архитектуру, пока что она +- больше всего подходит под SOLID, но со своими упущениями (под разные фреймворки, библиотеки), которые придется делать, если какие-то библиотеки юзаешь, допустим Redux в React, которые создает глобальные сторы. А так, стараешься всю логику из компонентов выносить, чтоб там только получать пропсы или использовать selectors если это Реакт (это не является бизнес логикой). Если что-то переиспользуется то выносишь в общие компоненты. Если будешь использовать FSD архитектуру, то у тебя будут просто карточки и будут widgets и feature компоненты, в которых как раз ты и будешь использовать бизнес логику, а потом в карточки передавать уже полученные и приведенные в нужный вид значения. Там же и будет логика отправки данных, сохранение и т.д. А в компонентах page, будешь просто собирать страницу из готовых элементов Widgets и Feature (которые будут самостоятельными и не зависимыми друг от друга)
Михаил, что скажете по поводу stylesX?
Пока не имел с ним дело.
Если вы по какой-то причине не пользуетесь муи, то наверное удобно.
Уже насколько лет не пользуюсь ни css, ни препроцессорами в принципе. А последние года два перестал пользоваться и clsx/classnames. styled-engine в муи хватает чтобы покрыть любые кейсы
MUI - хорошая штука. Но на проектах, кажется, только один раз попадалась. Они вроде сейчас свой CSS-in-JS подход разрабатывают.