В защиту методологии Utility-First CSS

От автора: композиция, а не наследование. Этот кусочек мудрости от Design Patterns, одной из самых влиятельных книг по разработке программного обеспечения, является основой utility-first. Он также разделяет многие принципы с функциональным программированием: неизменность, композитивность, предсказуемость и предотвращение побочных эффектов. Цель всех этих причудливых терминов — написать код, который легче поддерживать и масштабировать.

Впрочем, обычно новые CSS методологии вызывают настороженность. Несмотря на растущую популярность, Utility-First CSS все еще никого не убедил. Хотя одни хвалили его, а другие ярко критиковали такую практику. Раньше я был в последней группе. Я был поклонником BEM, реализовавшему подход, который я принял за его преимущества, и который в конечном итоге укоренился в нём, как в спортивной команде. Сначала я отказался от utility-first, потому что знакомый и любимый мне подход был не так уж хорош.

С тех пор я погрузился в эту тему гораздо глубже. Я изучил шаблоны проектирования и функциональное программирование. Это позволило мне радикально пересмотреть мои суждения.

CSS Tricks и Adam Wathan сделали блестящую работу, взяв нас в путешествие от «обычного» CSS к Utility-First и объясняя «почему» за ним. Вместо того, чтобы перефразировать, я сосредоточусь на постоянной критике utility-first попытаюсь развеять заблуждения.

«Можно ли также использовать встроенные стили»

Люди часто сравнивают utility-first CSS с применением CSS-правил для узлов HTML через style атрибут. Этот способ стилизации единогласно считается плохим, и с тех пор мы перешли к отдельным стилям и абстракциям классов.

Utility-first CSS ничем не отличается. Все стили определяются и поддерживаются отдельно. Это позволяет повторно использовать код, использовать псевдоклассы, псевдоэлементы, предварительные процессоры и кеширование браузера.

Тем не менее, хулители Atom CSS торопливо связывают его с встроенными стилями. Атомные классы малы, у них часто есть только одно правило, и они называются функционально, а не семантическими.

Все, что говорится, говорится потому, что оно выглядит одинаково, но это вовсе не означает, что это одно и то же. Понимание их отличий друг от друга, является ключом к пониманию преимуществ utility-first в первую очередь.

Встроенные стили позволяют делать все, что угодно. Вам не нужно следовать никакому ранее существующему определению. Вы переписываете все с нуля каждый раз, когда создаете новый узел HTML. Аналогичные элементы заканчиваются дублирующимся кодом, что делает страницу излишне тяжелой. Если вы не будете осторожны, будет легче игнорировать уже существующие решения и каждый раз изобретать колесо.

Неоправданно подробный, более тяжелый размер файла, несколько источников правды для единой концепции дизайна.

Три попытки решить ту же проблему. Это легко вызвано отсутствием единственного источника правды и может вызвать визуальные несоответствия.

Классы utility предоставляют четко определенный API, который можно использовать для составления более сложных компонентов. Вы не переписываете стили, а полагаетесь на классы, которые определяют стили и их поведение раз и навсегда.

Использование определенного набора существующих правил CSS, независимо от их количества, заставляет вас выбирать стили из ограниченного списка. Вам не предоставляется полная свобода, как со встроенными стилями. Вы поддерживаете согласованный каталог разрешенных стилей и используете их для макета из более крупных компонентов.

Такой подход обеспечивает согласованность, ограничивая способы стилизации элементов. Вместо того, чтобы иметь доступ к 16 миллионам цветов, вы получаете доступ только к числу цветов, определенных в вашей теме.

Он также обеспечивает единственный источник правды. Вместо повторного объявления одного и того же цвета для каждого элемента, который его использует, вы определяете его один раз в классе и используете этот класс там, где вам нужно. Кроме того, использование отдельного стиля (с атомными классами или нет) дает вам доступ к псевдоклассам и псевдоэлементам, предварительным процессорам, кэшированию … целому множеству преимуществ, которые недоступны во встроенных стилях.

Вы можете утверждать, что не имеет значения, ограничены ли атомарные стили: небрежное их смешивание может привести к несогласованным макетам, например, со встроенными стилями. Но это человеческий фактор, а не технический. Вы получаете ту же проблему с любым подходом и любым языком, независимо от того, можете ли охватить или нет. Если вы не соблюдаете правила, руководства по стилю и лучшие практики, которые ваша команда ставит на место, это ваша вина. Не программы, не языка, и не архитектуры.

«Это нарушает разделение проблем»

Один из главных аргументов против функционального CSS заключается в том, что он идет вразрез с задачами. CSS должен строго отвечать за стиль, а HTML — семантически структурировать страницу. И используя атомарные классы и составляющие компоненты в HTML вы делегируете стиль HTML вместо того, чтобы делать это в CSS.

В конечном счёте, это крайне искаженное видение того, что означает «разделение задач».

Несколько лет назад я был на собеседовании с изначальным разработчиком, который рассказал мне о своем презрении к Bootstrap. По его словам, использование дополнительной разметки для создания сетки — полная чушь: это работа для CSS и только. HTML должен на 100% соответствовать своему рендеру.

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

Адам Ватан достаточно хорошо объясняет это: когда дело доходит до HTML и CSS, нельзя смотреть с точки зрения строгого разделения интересов. Это «зависит от взаимоотношений».

Не ошибитесь: если композиция стиля выполняется в документе HTML, это не значит, что она сделана в HTML. Мы не используем стиль или выравниваем атрибуты на узлах HTML. Мы собираем фрагменты, которые мы определили в правильной таблице стилей в CSS. Наш HTML становится потребителем нашего API-интерфейса CSS. Как объясняет Vue.js в своей документации, разделение проблем не равно разделению файлов по типам. Ваши стили могут быть составлены на узлах HTML, но это все еще работа CSS.

«Это раздувает HTML»

Когда люди говорят о раздувании кода, это обычно означает одну из двух вещей (или обе сразу): код, который трудно читать, и более тяжелую кодовую базу.

Сложность вашего макета должна где-то существовать. Компонентно-первый подход не удаляет «раздувание», он только делит его на таблицу стилей. Тем не менее, поскольку ваши более крупные компоненты повторно используют те же самые атомные стили, что и другие, вы неизбежно получаете дублированный код.

Даже с Sass вы получаете повторяющиеся правила в исходном коде. @mixin может помочь, но вы все равно получите дубликаты в скомпилированном CSS.

Теперь я знаю, о чем вы думаете. Мы получили @extend. Это идеальный вариант использования, верно?

Не так быстро.

@extend может избежать дублирования набора правил в скомпилированном CSS, но мегасепаратор, разделенный запятыми, который он будет генерировать, может оказаться намного тяжелее, чем если бы вы просто дублировали правило. Так много нужно для того, чтобы избежать раздувания.

Вы также объединяете несвязанные классы и перемещаете их всех вверх, где происходит @extend. Это может быстро привести к проблемам специфики и странным переопределениям. Не говоря уже о том, что вы не можете использовать @extend как внешний класс или заполнитель из медиа-запроса. Так что да, определенно не лучшее средство.

С точки зрения размера файла, вы не должны беспокоиться о повторных именах классов в HTML. Для этого и нужен Gzip. Выкачивание алгоритма было специально создано для обработки повторяющихся строк, так что нет никакого смысла в вырезаниях символов в HTML. В результате размер файла не будет зависеть от того, используете ли вы множество классов или всего несколько.

С другой стороны, чем больше селектор повторяется в таблице стилей, тем больше работы ваш браузер должен сделать, чтобы разрешить все стили. Если у вас есть один .title-green класс для данного стиля, он просто соответствует всем .title-green на странице. Но если у вас много классов, которые делают то же самое (используя @mixin) или похожие селекторы, которые делают разные вещи (используя @extend), тем сложнее будет для браузера.

HTML «bloat» не имеет значения, но не для CSS. Сеть и движок не заботятся о том, сколько классов в вашем HTML, важно то, как вы пишете свои CSS-подсчеты. Если ваш процесс принятия решений вращается вокруг выступлений, убедитесь, что вы сосредоточили свое внимание на правильных вещах.

«BEM достаточно»

OOCSS и все производные методы (SMACSS, BEM и т. д.) значительно улучшили способы обработки CSS. Utility-First CSS является наследником этого подхода: она также определяет объекты многократного использования.

Проблема с BEM заключается в том, что он сначала фокусируется на создании компонентов. Вместо того, чтобы искать самые маленькие, нераспределяемые шаблоны, вы создаете блоки и их дочерние элементы. BEM отлично справляется с расширением имен и предотвращает утечку стилей, но его компонентная природа неизбежно приводит к преждевременной абстракции . Вы создаете компонент для определенного прецедента и в конечном итоге не используете его повторно (например, компонент навигационной системы).

BEM рекомендует использовать модификаторы для обработки изменений компонентов. Сначала это может показаться умным, но в итоге, к сожалению, приводит к другим проблемам. Вы создаёте тонны модификаторов, которые используете только один раз и только для конкретного прецедента. Хуже того: от одного компонента к другому вы можете оказаться в схожих модификаторах, что еще больше нарушит принцип DRY.

При масштабировании компоненты могут сильно измениться, не разбирая экземпляры на протяжении всего проекта. Преждевременная абстракция не позволяет компонентам эволюционировать и делиться на независимые объекты, если это необходимо. Модификаторы умножаются как попытка исправить это, приводя к нерегулярным вариантам использования unicorn, а также отказоустойчивым диапазонам, когда мы понимаем, что наш компонент делает слишком много.

BEM — отличная попытка исправить присущие CSS проблемы, но при этом основной подход CSS вашего проекта приносит все проблемы, которые вы встречаете, в пользу наследования над составом.

«Это совершенно другой язык на базе CSS»

Так же можно сказать о любой системе именования для любого конкретного проекта, независимо от выбранной методологии. Экосистема имен классов CSS — это слой абстракции поверх чистого CSS. Независимо от того, используете ли вы семантические имена, такие как .card или функциональные .bg, новые участники должны ознакомиться с тем, как, для чего и когда его использовать.

Вам не удастся использовать интерфейс именования между вашим HTML и CSS, если вы не хотите описывать свою точную разметку в CSS или писать встроенные стили. В конечном счете, имена функциональных классов легче понять, потому что они описывают стиль. Вы знаете, что они делают, не просматривая фактические стили, а семантические имена заставляют вас либо смотреть на код рендеринга, либо просматривать стили.

«Это недостижимо»

Когда люди говорят, что utility-first CSS недостижим, они часто упоминают, что, когда что-то меняется в дизайне, вы должны менять это везде. У вас есть кнопки с прямыми углами, и вы решили сделать их округлыми, поэтому вам нужно добавить .rounded-corners класс utility на каждую кнопку в коде. Тем не менее, весь смысл utility-first — прежде всего, это то, что вы начинаете составлять классы utility, а затем создаете компоненты, когда начинаете определять повторяющиеся шаблоны.

Кнопка является идеальным и наиболее очевидным кандидатом для того, чтобы быть абстрагированным в свой собственный компонент. Возможно, вам даже не понадобится проходить фазу «utility-first, а затем компонент» для этого случая. Когда дело доходит до более крупных компонентов, в пользу композиции first является лучшим выбором для ремонтопригодности. Зачем? Поскольку безопаснее добавлять или удалять классы на определенном узле HTML, чем добавлять или удалять стили в классе, который применяется ко многим элементам.

Слишком много раз я подвергался меняющимся проектам и должен был дублировать существующие компоненты, чтобы заставить их вести себя по-другому, потому как у меня не было другого выбора. Даже когда дизайнер поставляет все проекты в начале проекта, и даже если вы отлично справляетесь с определением компонентов перед кодом, вы не можете предсказать будущее.

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

Это решение является простым, семантическим и многоразовым. Вы обрабатываете всё в CSS и имеете минимальный HTML-код для записи. Но вдруг вы получаете новые проекты для новых страниц, и они используют карту без ленты. Теперь вам нужно найти способ удалить ленту для этих новых карт.

Проблема в том, что этот класс уничтожает то, что было разработано ранее. Необходимость добавления класса для удаления функции — это анти-шаблон: он интуитивно понятен и неспособен поддерживаться. Когда вы решите изменить поведение базового класса, вам нужно следить за модификатором отмены, чтобы убедиться, что он все еще работает.

Теперь нам нужно добавить еще одну ленту в левую нижнюю часть.

Но теперь нам нужно обновить .card-no-ribbon!

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

Единственный вариант, который остаётся на этом этапе — это сделать рефакторинг: использовать голый .card в качестве базового класса и добавить ленту с помощью модификаторов .card—top-ribbon и .card—bottom-ribbon. Но теперь нужно изменить все существующие .card в коде, которые действительно нужны в ленте.

Ранние рефакторы — довольно хороший показатель неподдерживаемости.

Можно утверждать, что умный разработчик должен видеть, как это происходит. То, что они должны были сделать с самого начала — голый базовый класс .card и модификатор .card—ribbon.

Фактически это аргумент в пользу Utility–first и композиции.

Вы принимаете решение разбить элемент дизайна, который считаете слишком монолитным, поэтому его легче масштабировать. Это хороший звонок. Чем дальше вы заходите, тем быстрее поймете, что это приведёт к utility-first.

Вы можете подумать, что это не так, и что ваша задача — предвидеть,что является минимальным для данного компонента. Но если вы не обладаете хрустальной чашей, это рискованная оценка. Это совсем недальновидно. Что делать, если части вашего компонента необходимо распространить на другие компоненты? Например, что, если теперь вам нужны кнопки с лентами? Если вы дублируете .card—ribbon класс, ваш код больше не DRY, что делает его еще более незаменимым. Так? Сделать микширование и импортировать его в оба модификатора? Опять же, это дополнительная работа и «мокрый» код.

Лучшим решением для этого варианта использования является запись одного класса utility для ленты, а также модификаторы для размеров и цветов, если это необходимо. Это позволяет вам иметь единственный источник правды и использовать ленту в любом месте. Если вам нужно поместить ленты на аватарах, панелях, неупорядоченных списках, модулях, вы можете сделать это, не создавая лишнюю строку CSS.

Это определение масштабируемости и ремонтопригодности. Все, что вам нужно сделать, это повторно использовать имеющийся код, который вы написали проактивно, вместо того, чтобы настроить существующий код реактивно.

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

Вызов «неподъёмной» utility-first CSS — абсолютно неточный. Фактически, это может быть самая поддерживаемая и масштабируемая методология CSS по сей день.

Вы не можете предсказать будущее. Вот почему вы всегда должны отдавать предпочтение композиции, а не наследованию. Хорошим признаком здоровой и масштабируемой кодовой базы является то, как все происходит, когда вам нужно ее менять.

Если новое изменение заставляет вас беспокоиться, потому что вы можете что-то сломать, это признак плохого дизайна. Но я хотел бы немного забежать вперёд и сказать, что если вам нужно написать новый CSS, чтобы сделать существующий компонент, делайте то, что уже делает другой компонент, код не будет настолько масштабным, как вы думаете.

Если вам нужно повторно использовать поведение, которое существует где-то, вам не нужно писать новый код. Вы должны быть в состоянии доверять и использовать то, что вы уже писали, и отталкиваться от этого. У вас есть один источник правды, на который вы можете положиться, вместо двух или более незначительных вариаций, которые вы не должны забывать постоянно обновлять. Это определение ремонтопригодности.

«Уродливый и трудно читать»

Помните шумиху, когда BEM стал популярным? Я помню. Я помню многих людей, которые отвергли его из-за его синтаксиса. Восхваление модели, но отвращение к идее цепочки двух подчеркиваний или двух дефисов.

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

Посмотрите на исходный код многих крупных проектов: большинство из них закончили тем, что приняли BEM. Скорее всего, не все их front-end разработчики были реализованы в начале.

Преодолеть начальные чувства, особенно если они обусловлены личными предпочтениями, не так уж сложно, когда вы во главу ставите успех проекта.

Теперь о теме разборчивости: я знаю, что длинные строки классов могут оказаться «страшными», когда вы открываете файл в первый раз. Однако это не является непреодолимой задачей. Более подробный код — это компромисс композиции, и это лучше, чем невозможность.

Я не использую сокращения, как .pt-8 или .bb-lemon в своём собственном коде. Я предпочитаю полноразмерные имена классов, такие как .padding-top-8 и .border-bottom-lemon, которые намного легче читать. Автозаполнение решает проблему ввода длинного имени класса, и есть инструменты, которые вы можете использовать для повторного использования имен классов в более мелкие для производства. Я сомневаюсь, что это внесет какие-либо существенные изменения в ваши выступления, но эй, если из-за этого вы лучше себя чувсвуете, то почему бы и нет.

В конечном счете, характер имен функциональных классов может быть более выразительным. Для вашего мозга легко установить связь между классом и тем, что происходит на экране. Даже если вы не увидите, как это проявляется, вы можете довольно чётко представить, что .hidden или .opacity-6 должны делать.

Довольно легко понять, что здесь происходит.

Семантические имена классов не передают одно и то же. Он работает для небольших компонентов, таких как кнопки или предупреждения, которые достаточно распространены, чтобы их можно было легко распознать. Тем не менее, чем больше и сложнее компонент получается, тем менее очевидно, какое имя класса сопоставляется с тем, что на экране, или как оно выглядит.

Труднее узнать, что делает класс, не проходя через таблицу стилей.

Таким образом, функциональные классы намного легче понять, чем имена семантического класса. Они требуют меньше времени на понимание и меньше переключений файлов. В конечном счете, они дают вам очень немного информации, которую вы и так ищете.

«Вы не так пишете CSS»

Специфика CSS — это особенность, а не ошибка. Используйте её правильно, и это даст вам потрясающий контроль.

Это то, что говорят ветераны CSS, когда появляется еще одна статья об опасностях специфики. И технически они правы: система приоритетов CSS — это не случайность. Обычно это беспокоит людей, которые не осваивают CSS из-за недостатка возможностей. Но язык не нарушается от того, что он не ведет себя так, как вы привыкли. Вложенные правила CSS подобны !important: они удобны, но годами использовались так плохо, что мы теперь видим это как то, чего следует избегать.

Специфичность следует использовать проактивно, а не реактивно. Она должна быть дизайнерским решением, а не быстрым решением, если вдруг стили не применяются. Гарри Робертс хорошо объясняет это в Руководстве CSS:

«Проблема со спецификой не обязательно в том, что она высокая или низкая; факт в том, что это такой вариант, и что его нельзя исключать: единственный способ справиться с ним — постепенно становиться более конкретным».

Специфика — мощный инструмент, но его необходимо использовать с большой осторожностью и уверенным долгосрочным видением проекта. Используйте их неправильно, и вы почувствуете боль от необходимости начинать всё сначала. Сохранение специфичности в целом позволяет избежать проблем: оно опирается исключительно на исходный порядок, которым намного проще управлять . При использовании атомарного CSS, если стиль не применяется, исправление его так же просто, как добавление или удаление класса на узле HTML. Вам не нужно вызывать структуру вашей таблицы стилей, что намного проще и безопаснее.

«Если функция иногда опасна, и есть лучший вариант, тогда всегда используйте лучший вариант». — Дуглас Крокфорд

Использование специфики или отказ от неё — это не то, насколько хорошо вы изучили CSS и как, в отличие от других, можете держать его под контролем. Речь идет о понимании преимуществ и недостатков функций, имеющихся в вашем распоряжении, и принятии решений в интересах проекта.

«В итоге у вас много неиспользованного CSS»

Предположим, вы используете карты Sass для создания ваших utility классов . Цвета, размеры шрифтов, фоны, всё автоматически компилируется в правильный, готовый к использованию CSS. Проблема в том, что, если вы не используете всё, у вас останутся бесполезные дополнительные байты в производстве. Это можно легко установить с помощью UnCSS.

UnCSS отлично справляется с вашими стилями, но поставляется с двумя оговорками: он работает только с файлами HTML (без PHP и без файлов шаблонов), и он учитывает только JavaScript, который выполняется при загрузке страницы (а не классы, добавленные в пользовательские взаимодействия, например). Если вы используете язык, такой как PHP, чтобы отображать ваши страницы, вы можете добавить задание в рабочий процесс развертывания, который компилирует страницы во временный HTML и запускает UnCSS. Для второй проблемы вы можете использовать опцию ignore, чтобы указать, какие классы добавляются при взаимодействии с пользователем.

Теперь важно также подумать над этой проблемой. Стоимость неиспользуемых классов — это более тяжелые таблицы стилей (дольше для загрузки) и более длительное время синтаксического анализа. Если у вас много, и я имею в виду большой процент ваших общих стилей, неиспользуемых классов, это может повредить выступлениям. Если у вас есть только немного здесь и немного там, воздействие будет незначительным.

Поддержание вашей кодовой базы CSS — это ваша работа в качестве разработчика. Независимо от того, какую методологию вы выберете, вы должны следить за проектом и не забудьте удалить мертвый код, когда всё поменяете.

Небрежность в этом — это то, как получается множество неиспользуемых классов, а не создание некоторых из них.

Нужен текстовый класс цвета только для основного цвета? Сделайте класс только для этого. Нужны фоны для большинства цветов в теме, но вы не уверены, что сможете использовать их сразу? Создайте проклятые классы. Они будут готовы, когда это будет нужно, и вам не придется поддерживать их, когда вы добавляете новые цвета, а дополнительный код ничего не будет стоить. Это не узкие места приложения. Если у вас проблемы с исполнением, есть еще миллион других вещей, которые нужно рассмотреть, прежде чем заглядывать в CSS.

«Это затрудняет понимание того, что доступно для использования»

Когда ваша CSS-кодовая база представляет собой большую коллекцию небольших классов utility, чтение исходного кода не поможет вам получить качественный обзор доступных стилей. Но в любом случае это ли роль исходного кода?

Это, конечно, не так. Вот для чего нужны руководства по стилю.

Изучения исходного кода абсолютно недостаточно, чтобы получить правильное представление о том, как разработан полный API. Он не ограничивается атомными CSS: проекты OOCSS или BEM, даже небольшие, могут достичь уровня сложности, который требует по крайней мере README.

Можете ли вы себе представить, что придётся ползти обратно в unminifed версии мастера стилей Bootstrap каждый раз, когда вы не помните, это .col-md-offset-6 или .col-offset-md-6? Может ли кто-нибудь из новичков Bootstrap понять, что такое класс, без небольшой литературы о том, как работает сетка? Документация, руководства по стилям и ссылки API предназначены для того, чтобы помочь нам разобраться в сложных системах. Несомненно, это не значит, что документация должна оправдывать плохой дизайн и нечеткие соглашения об именах, но думая, что вы должны понимать весь проект, только читая исходный код, это чистая фантазия.

Существует множество инструментов, которые помогут создать документацию прямо из кода. Я использую KSS для большинства своих проектов, но CSS-Tricks разделяет список альтернатив. Попробуйте!

«Классы utility должны использоваться вместе с компонентами»

Да. Абсолютно. Именно поэтому это называется utility-first, а не utility-only.

Utility-first ни коем образом не касается канальных компонентов. Это означает, что начинать следует с классов utility, используя большинство из них и только абстрактно, когда вы видите повторяющиеся шаблоны. Вы позволяете проекту расти, сохраняя гибкость и определяя фактические компоненты с течением времени, когда модели начинают появляться.

Крайне важно понять, что компонент — это не просто «блок», который можно повторно использовать. Это шаблон, который привязан к конкретному проекту. Конечно, вы, вероятно, собираетесь использовать тонны .btn и .modal, поэтому имеет смысл абстрагировать их на раннем этапе. Но вы уверены, что собираетесь использовать его снова .testimonial? Или, по крайней мере, повторно использовать так, чтобы сделать его новым компонентом? Будет ли он всегда выглядеть так в любом контексте или он специфичен для главной страницы? Держите свои варианты открытыми. Это намного проще, чем потом абстрагировать сложный стиль в компонент, или пытаться его отменить.

«Перепроектирование / тематический кошмар»

Поскольку атомный CSS напрямую привязан к вашему дизайну, это может усложнить ситуацию, когда вам нужно сделать редизайн или разработать альтернативную тему. Однако это далеко не невозможно, и есть несколько вещей, которые вы можете сделать, чтобы Utility-first CSS больше подходил в случае таких потребностей.

Вы можете начать с того, что имена классов не слишком специфичны. Вместо этого .margin-bottom-8 вы можете использовать более абстрактное имя .margin-bottom-xxs. Таким образом сможете изменить значение, не делая имена недействительными.

Другим подходом было бы создание псевдонимов . Представьте, что вы создаете приложение со светлым и темным режимами: некоторые цвета меняются, другие- нет. Мы не хотим, чтобы все наши утилиты цвета были контекстуальными: .background-primary и .background-secondary, не говорите нам, какой цвет стоит за классом. Нам не нужна такая система цвета. Тем не менее, всё еще существуют цветовые утилиты с правильными именами цветов ( .background-lime или .background-red) и сгенерированные псевдонимы для тех, кому такие могут потребоваться для изменения целей.

Здесь вам нужно всего лишь написать функцию JavaScript, которая переключит все .*-light и .*-dark классы. А для элементов, которые не нужно изменить, вы можете использовать исходные классы цветов.

Этот метод работает хорошо, но если у вас уже есть множество классов для переключения, это может привести к ухудшению производительности. DOM-манипуляции дорогое удовольствие. Нужно сократить их как можно сильнее, если сможете. К счастью, есть отличная методика, включающая переменные CSS (благодарю Адаму Уатану за то, что он придумал), что очень сильно всё упрощает.

Мы определили цвета с переменными CSS и присвоили разные значения для каждого контекста. В зависимости от охватывающего класса все цвета будут меняться благодаря наследству предков . Если вы разрешили переключение темы, всё, что вам придется сделать, это изменить .theme-light в .theme-dark на родителях

Метки: css

Похожие статьи: