Ты не можешь построить жизнеспособную дизайн-систему на Tailwind — Часть 1

[vkomp]

Не понял сабжа. Если делаешь универсальное решение, то по дефолту оно и является проблемой. Просто управляем сложностью, и рядом с XButton может быть XButton2 - норм.
Про cva вы умолчали, что наряду с VariantProps-параметрами остается доступный className, куда можно добавить своё накопившееся.

[m_ig]

Универсальное решение возможно только для функциональных вариантов кнопок - primary, default и тд. Для вариаций связанных с размерами или наличием иконки внутри - такие правила не задать.

Смысл проблемы как раз таки в наличии четких правил для одних вариантов, и их комбинации с другими вариантами.

Про CVA - я разбираю идею и подход вокруг которой строится система. А не костыли чтобы реализовать что-то. А так классы конечно там можно добавить. Но тогда зачем вообще tailwind если снова все уперлось в стили?

[vkomp]

Норм там с иконкой внутри и без. Четвертый tailwind умеет в хитрые штуки типа селекторов потомков. И умеет в data-атрибуты. Уверен, вы видели это в shadcn - я оттудова копипастю и адаптирую под себя.
Так кусочек, когда нужно для xs только иконку, а текст в span прятать и оставлять только img/svg-иконку:
adaptive: { true: "[&>span]:hidden sm:[&>span]:inline", false: ""}
Еще в cva есть compoundVariants, когда просто variants не хватает. Здесь размер кнопки + текст/нет:
compoundVariants: [
// отступы, если есть span-текст
{ adaptive: false, size: "md", class: "has-[>span]:px-3" },
{ adaptive: false, size: "lg", class: "has-[>span]:px-4" },
{ adaptive: true, size: "md", class: "sm:has-[>span]:px-3" },
{ adaptive: true, size: "lg", class: "sm:has-[>span]:px-4" },

Да, все в css переводится. Но работает, и это уже хорошо

[m_ig]

ну честно это не выглядит все как стабильное решение для какого-то крупного проекта :-)
Там же они не просто так используют icon-xs" | "icon-sm" | "icon-lg" вместо того чтобы просто совмещать вариант с icon и размер.
Попробуйте совместить primary + outline + xs кнопку -- придется снова придумывать какой-то костыль.

[vkomp]

Эти три соединяются в обычном variants. Если можно в прозрачность, то ставится основной цвет text-success-700, а фон задается bg-current/5 сразу для всех вариантов. Вот с variant=solid такой фокус не срабатывает и там уже compoundVariants и длинное "text-success-50 bg-success-700".
Все равно куча кнопок, но скорее из-за логики. Например, кнопки download/upload выделены в отдельные с наследованием ts-пропсов.
А если какая-то редкая замысловатая кнопка, то проще стилизовать на месте, а не мудрить в универсальность. У всех компонент какой-то жизненный цикл. А "одна кнопка для всего" - зло.

[m_ig]

я говорил про пример который я приводил из shadcn
дефолтная кнопка + outline - это по сути взаимоисключающие варианты там и их нельзя никак вместе использовать
---
мой пойнт не в том чтобы создавать кучу вариантов кнопок, а в том чтобы создавать модификаторы кнопок и комбинировать их между собой при необходимости. Т.е. список вариантов - не линейный, а идет в двух измерениях.

Простой пример: в текущем исполнении shadcn возможны 48 комбинаций из типов кнопок и размеров.

Если же ты добавляешь чуть больше гибкости:
variant: "default" | "ghost" | "destructive" | "secondary" | "link" "default" size: "default" | "xs" | "sm" | "lg"
icon: yes / no
outline: outlined / solid
то таких комбинаций становится уже 80.
---
С первым вариантом предлагаемая архитектура Tailwind может более-менее справиться. Но серьезные проекты требуют второго.

[Kahelman]

А ещё есть вариант Микеланджело: отрезать все лишнее- выкинуть ваш специальный тип кнопки оставить только стандартные.

[m_ig]

Боюсь продакт и дизайнер будут против 😅

[Kahelman]

У дизайнера работа - фигню придумывать, иначе ему деньги перестанут платить

[m_ig]

Это конечно ваше мнение, но оно в корне - неверное :-)

[shirmanov]

С нетерпением ждём Часть 2 с описанием, как построить жизнеспособную дизайн-систему на Tailwind.

[m_ig]

К сожалению там будет продолжение — почему нельзя. Мне сильно не нравится его концепция хотя я и понимаю почему он настолько сейчас популярен.

[Delka]

Вангую в продолжении будет про @apply, @variant и нейминг классов по BEM / разделение на компоненты.

В итоге окажется что после всех этих усилий мы наконец получаем возможность просто писать нормальный css :) а Tailwind становится просто лишним слоем синтаксического сахара.

[m_ig]

А вы смешной :-)

И по всем пунктам — нет. Это не посыл моей статьи и не то что будет во второй части.

[YuriyUl]

Поскольку не нужно переключаться между файлом компонента и файлом стилей, код пишется значительно быстрее.

Серьёзно? и сколько секунд вы наэкономили?

[m_ig]

Мне кажется вы не совсем в теме. Сейчас Tailwind - это 80% всех загрузок CSS фреймворков. Фактически сейчас это стандарт, особенно если брать стек связанный с реактом. Все новые UI библиотеки пишутся сейчас поверх него.

То что я привел тут - это не мое мнение. Я то как раз отношусь к нему негативно.
Это мнение разработчиков активно на нем пишущих. И вполне адекватное мнение, потому что если вам не нужно постоянно переключаться между файлами и искать глазами нужную строку, то это экономит много времени и увеличивает скорость разработки. При его использовании вы пишите все нужные классы прямо в шаблоне.

Собственно это и есть концепция, лежащая в его основе и которая сделала его популярным.

[nektobit]

Я могу

[WildeDJ]

Мне кажется автор не доконца изучил варианты использования. Можно посмотреть не на китайский копипаст shadcn, а к примеру на daisyUi, они ближе интегрированы с ТВ. Плюс вы забываете что можно определять переменные в arbitrary style, и на их основе строить композиции вариантов. Тогда вообще не важно какие там цвета