-
Использование модификатора !important чтобы перебить другие классы (стили).
Использование !important в 99% не нужен. Только в крайних ситуациях, когда работаете со сторонними библиотеками и привычными способами не получается повысить силу селектора.
Плохой код:
className={cn( 'bg-slate-100',{ '!bg-slate-200': isActive, })}Хороший:
className={cn('bg-slate-100', 'active:bg-slate-200')}На крайний случай, условное добавление классов:
className={cn({ 'bg-slate-100': !isActive, '!bg-slate-200': isActive })} -
Некорректная настройка или отсутствие корректных настроек в файле tailwind.config.js.
Полная замена tailwind цветов:
module.exports = { theme: { colors: { customColor: '#1DA1F2', }, }, };Расширение (добавление) новых цветов:
module.exports = { theme: { extend: { colors: { customBlue: '#1DA1F2', customGreen: '#10B981', }, }, }, };Если заменяете стандартные шрифты, то заменяйте все:
theme: { fontFamily: { sans: ['Roboto', 'sans-serif'], // Заменяем стандартный sans шрифт serif: ['Merriweather', 'serif'], // Заменяем стандартный serif шрифт mono: ['Fira Code', 'monospace'], // Заменяем стандартный моноширинный шрифт }, }Также сюда можно отнести неумение переопределять переменные tailwind.
Например, лучше в конфигурации заменить переменную для transition, время анимации, чем каждый раз дописывать класс duration-500.
transitionDuration: { DEFAULT: '500ms' } -
Распространенное использование класса transition-all для переходов.
Когда вы используете transition-all, браузер отслеживает и анимирует все изменяющиеся свойства, даже если они не требуют анимации. Это приводит к излишней нагрузке на рендеринг, так как браузеру приходится вычислять все возможные переходы, включая те, которые могут оказаться тяжёлыми для системы, например, изменения width, height, left, top и других свойств, влияющих на перерисовку и перерасчёт макета.
Либо указывайте конкретные свойства которые необходимо "анимировать", либо применяйте класс transition, в нем.
-
Одержимость произвольными значениями
<div class="bg-[#3498db]">Content</div> <div class="p-[20px]">Content</div>Лучше выносить в tailwind.config.js, и иметь стабильную дизайн систему, лучше иметь ограниченные стили, чем много.
extend: { spacing: { '20': '20px', }, colors: { // Добавление кастомного цвета для фона 'customBlue': '#3498db', }, }, <div class="bg-customBlue">Content</div> <div class="p-20">Content</div>Но лучше давать адекватные название для цветов, а то customBlue плохое. Можно заменить стандартный.
extend: { colors: { blue: { 500: '#3498db', // Заменяем конкретный оттенок 600: '#2980b9', }, }, }, -
Некорректное использование breakpoints
Забывание базового стиля для мобильных устройств: Важно помнить, что в Tailwind CSS базовые стили применяются к мобильным устройствам по умолчанию (для экранов меньше
sm). Если вы забыли указать базовый стиль, он может быть перезаписан на более крупных экранах.<div class="sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content</div>Проблема: Если экран устройства меньше
sm, то не будет применяться никакого фона, так как для мобильных устройств (по умолчанию) не задано никакое значение для фона.<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">Content</div> -
Извлечение класса @apply на глобальном уровне (создание собственных стилей, взамен изолирования на уровне компонента)
Желательно применять напрямую к компоненту, благо у нас есть компоненты в react или vue.
@layer components { .btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; } }Разработчики tailwindcss также рекомендуют оставлять стили в самих элементах, а не создавать классы через @apply, это громоздко, но зато не нужно идти и править там.
Но также видел проекты, где на уровне компонентов использование @apply и ф-ции реализующие подход css in js.
Выводы
Если обобщить, то проблема кроется в плохом знании css и документации tailwindcss. А как часто бывает, нанимают только начинающих разработчиков компании чтобы сэкономить денег. Вроде бы получают как по макету, но код получается грязным. В добавок к этому добавляется проблема с семантической версткой, доступностью и сломанной логикой компонентов.
Делитесь своими плохими практиками, как не стоит или как стоит. Возможно у вас были открытия, которые вам упростили жизнь.
Комментарии (18)
dom1n1k
14.11.2024 05:39Лучше выносить в tailwind.config.js
Это одна из странных для меня вещей в тайлвинде.
Цвета/шрифты/отступы/етц в переменных это окей, но почему черт возьми они лежат в конфиге? Конфиг это конфиг, какие-то технические настройки библиотеки. А дизайн-система – это стили, неотъемлемая часть проектного кода, почему она не лежит в src, где-то неподалеку от компонентов?
markelov69
А разве само по себе использование tailwindcss не является ошибкой?
Это же максимально нелепо, и это тут ещё стилей с гулькин нос.
Есть же SCSS, идеальный инструмент для работы со стилями. Там тебе и миксины и переменные и условия и циклы и т.д. и т.п.
Но нет, вы не хотите что бы всё было красиво и просто, вы хотите страдать.
francyfox
tailwind используется для коммерческой разработки, когда людей много. Как думаешь сколько выхлопа css будет если они будут писать ручками или использовать классы к которым уже привязаны стили.
Я не помню когда уже вообще использовал миксины или циклы, ну может когда потребовалось делать рандомные цвета, но это редкий случай. Sass переменные вообще использовать нельзя, их нельзя переопределить через js
Есть же postCss, который может делать еще больше и он быстрее
clerik_r
Вообще не вижу тут логику и здравый смысл. Какая разница сколько людей? Если работник #6 делает компонент DatePicker'a скажем, какая разница tailwind или css/scss/и т.п.? При чем тут коммерческая разработка? При чем тут кол-во людей?
Компонентный подход, нет? А для всего остального оверхед в несколько килобайт в масштабах проекта это вообще ничто, причем ничто с большой буквы. Потому что в противовес
против
Ну тут как бы все очевидно. Более того, ты никак не зажат по стилям в отличии от tailwind.
Не расстраивайтесь, если вы знаете как их применять и для чего. Ещё наберетесь опыта. Умные и опытные дядьки приведут вам примеры.
Вот один из них:
Я надеюсь вы слышали о таком понятии как адаптивная верстка?
Ну ка, что может быть более удобнее, очевиднее, читаемее, красивее чем вот это?
Где
Да вы что? Вот прям так, да? Какой кошмар, 9 лет использую, а оказывается нельзя. Ну если вы не знаете о проектировании и что и как лучше использовать, то это сугубо ваши проблемы)
Что?) Для каких утех ради?)) Наверное вы имеете ввиду переключение светлая тема/темная тема?)
Так то есть переменные нативного CSS если вы не в курсе.
var(--base-text-color);И их можно переключать через js) А ещё секрет есть, не знаю, вы наверное не поверитеПеременные SCSS могут содержать переменные CSS. Вот это поворот)
francyfox
я говорю что каждый пишет по своему. Мне код после другого разработчика проще прочитать на tailwind, чем фигню которую напишут в css. В стили мы помещаем только псевдоселкторы, фоны и тд. что нельзя запихнуть в классы tailwind.
Миксины зло, потому-что люди злоупотребляют ими. Когда в коде видишь scss миксин сложнее блока из js, начинаешь скрепеть зубами. Tailwind ни так красив и ни компактен, да это зачастую лишняя div вложенность. Но это фреймворк, а значит накладывает свои законы и правила. В scss проще сотворить дичь.
в одном проекте это будет
@mixin respond-to-desktopв другом@mixin adaptive-XLв другом@include respond($desktop)в другом@media (min-width: 30em) and (max-width: 50em)и пошло поехалоclerik_r
Фигню? Это какую? font-size? padiing? display? такую фигню? Вы вообще в курсе что такое css и какие в нем стили бывают? Или всё что вы видели это
bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500?Что за бред, вы себя под всех подписываете? Если вы не в курсе что это, и как этим пользоваться, то это не говорит о том, что это зло.
Javascript - зло, потому-что люди злоупотребляют им.
Ну и в таком же духе для всего остального, надеюсь вы поняли абсурдность сие высказывания.
Какую конкретно?) Вы опять подписываете всех под себя?) Если вы пишете дичь в scss/css, то опять же, это сугубо ваши индивидуальные проблемы.
В Javascript проще сотворить дичь.
В PHP проще сотворить дичь.
В Angular проще сотворить дичь.
Ну и так далее по списку.
И что? Как бы названия этих функций говорят сами за себя. Один раз вы их увидели и используйте нездоровье. Плюс никто не запрещает сделать для них алиасы, где:
@mixin respond-to-desktop === @mixin adaptive-XLДа, всё что тут перечислили это жирные минусы.
И это тоже жирный минус.
Ну точнее может для совсем зеленого джуна который первый месяц в разработке это норм. Но для всех остальных, это жирный минус. Ибо связывать руки и ограничивать можно только тех, кто не ведает что творит, остальным это сильно мешает и вставляет палки в колеса.
Но если для вас это не очевидно, то вы пока всё ещё относитесь к категории которых лучше ограничивать во всем и не давать сделать шаг влево шаг вправо.
ko22012 Автор
не хотите схлеснуться в легендарной битве, где один будет на tailwindcss, другом на scss писать код. Оценим качество работы, сам код и время сколько ушло, как такая идея?
francyfox
зачем мне убеждать его? У него пена из-за рта уже пошла. И при чём здесь скорость? Он не быстрее (хотя если пишешь рутину в стиле display: flex почему не воспользовать готовым). И никто не говорит про полный отказ от обычных стилей. Атомарный CSS занимает свою нишу в разработке и это в основном крупные компании, посколь проще поддерживать проекты. Вот и всё ;) Если бы это было ни так, не было бы вакансий с упоминанием tailwind, windi, unocss
clerik_r
А ещё есть вакансии с упоминанием Angular2, ExtJs и прочими "замечательными" технологиями. Занимайтесь.
Да, это прям мечта, так классно и просто поддерживать, прямо загляденье. Вот мы идиоты то, мучаемся, используем scss/css, и пишем ужасные display, padding, font-size и т.п. Бррр, аж кровь из глаз течет от этих ужасных свойств. Ох, а если миксин заюзать, ууу тогда пиши пропало вообще.
clerik_r
Целиком делать проект нет смысла, да и сравнивать скорость нет смысла, ибо ctrl+c / ctrl-v из фигмы всегда быстрее.
или fz + tab + 16px =
font-size: 16px;как минимум не уступает сокращениям из tailwind.Просто повторите аналогичный стиль для кнопки, где
@include typography('Text Thin_14');пусть будет
@include typography('Text Regular_16', '#fff');пусть будет
francyfox
на хабре уже боты комменты пишут? при чем здесь angular? Тэги реакт и Vue. Речь шла про css фреймворк. Нафига столько кода в комментах?
STingerOid
А если туда ещё и CSS modules добавить, то станет ещё идеальней)
Никогда не понимал почему существует Tailwind.
clerik_r
С козырей зашли)
ko22012 Автор
Удобно не удобно, но все же есть вакансии где требуется знание tailwindcss, наблюдается его популярность при создании верстки с нуля. Чтобы каждый раз не создавать css. Если у тебя лэндинги, где не нужна поддержка, это будет идеальное решение для быстрого клепания.
markelov69
И что теперь? Это не делает этот "инструмент" отвратительным.
против
Что, серьезно? Вам самому не смешно?
Идеальное? Жесть, даже для write only once говнокода это перебор. Тем более вообще ничего с быстрым клепанием тут общего нет, если сравнить с css/scss, ctrl+c - ctrl+v стилей из фигмы в css, вот где быстро клепание, а не вот это вот всё.
ko22012 Автор
я ленивый программист, если можно сэкономить время разработки и деньги заказчика, я это сделаю, принимая во внимание еще сам продукт.
Я привык использовать готовые библиотеки, а не писать их с нуля. Зачем для каждого мелкого - среднего проекта делать свой ui кит? Если можно позаимствовать готовые, покрытые тестами и без нарушения семантики и стандартного поведения компонентов.
А на счет классов, вам никто не мешает использовать директиву @apply
Плюс еще подобные системы задают скелет для дизайн системы и в процессе сборки неиспользуемые классы из tailwind не добавляются.
Использование готовых утилитарных вещей экономит время. У вас могут быть готовые наработки на scss, которые вы можете из проекта в проект переносить, но не у всех они есть.
Взять тот же mui, мне очень удобно использовать на компонентах props, которыми я могу указывать отступы, цвет и т.д., разработчики позаботились о кастомизации; хотя это может быть спорно, т.к. гибкости там не так много.
evgeniyPP
Ваши аргументы убедят любого новичка, который никогда не сталкивался с версткой, это точно.
В реальности же Вы просто спрятали всю сложность своего примера в других файлах, как это обычно делается в подобных манипуляциях. А пример с TailwindCSS максимально нелепый, вы просто накопипастили какую-то белиберду, чтобы она и выглядела, как белиберда. На самом деле же, код с TailwindCSS зачастую намного читабельнее Вашего.
Вот Ваш пример, примерно написанный на TailwindCSS:
Может отпугнуть, если не знаешь, что значат эти классы. Но даже если не знаешь, можно разобраться, если напрячься. А если умеешь с таким работать, это становится максимально удобно и понятно.
В Вашем же примере я не вижу, как всё стилизовано; чтобы что-то поправить, мне приходится искать файлы со стилями, а так еще импорты в десять других файлов и пошло поехало; если у меня уже есть класс, а конкретно тут нужно еще отступ добавить, что мне делать, это целая проблема; нужно придумывать имена для каждого элемента на странице; нужно переживать на специфичность, чтобы стили не накладывались; для каждого компонента нужно держать отдельный CSS-файл, а значит количество файлов и папок сразу удваивается; и т.д. и т.п.
Я делал и так, и так, и прекрасно понимаю все подводные камни обоих вариантов. И для меня абсолютно очевидно, что TailwindCSS намного превосходит любые Ваши предложения. А Вы никогда не писали на TailwindCSS, и в своем невежестве продолжаете проталкивать устаревшие подходы.