Современные подходы к организации и работе с CSS в проекте

Любой, кто писал CSS в течение некоторого времени, знает о сложностях, которые с этим связаны, и о том, насколько это может быть болезненно.

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

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

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

Но прежде чем мы начнем, я хотел бы привести список некоторых важных CSS-концептов, которые должен знать каждый разработчик, работающий со стилями:

• Селекторы
• Модальный блок
• Значения и единицы измерения
• Положение
• Отображение
• CSS макет: Flexbox и сетки
• Отзывчивый дизайн

Ванильный CSS

Большинство из нас боится прикасаться к необработанному CSS. И это вполне оправдано.

Ниже приведен список проблем, связанных с CSS:

• Большая база кода
• Глобальное пространство имен (коллизии имен)
• Зависимости
• Устранение мертвого кода
• Минификация
• Совместное использование констант
• Недетерминированное разрешение
• Изоляция

Большая база кода, которую необходимо поддерживать и сопровождать

Вам нужно покопаться в таблице стилей. Чаще всего это означает просмотреть 1000 строк CSS. Искать медиа-запросы и то, как все остальное сочетается вместе. Когда вам нужно внести изменения в пользовательский интерфейс, проще всего создать новый класс CSS и забыть обо всем, что было написано ранее. Но вы можете создать дубликат CSS.

Глобальное пространство имен (коллизии имен)

Одна из известных проблем CSS заключается в том, что все селекторы являются глобальными. Неважно, как мы организуем наши стили, используя пространства имен или такие процедуры, как методология Block, Element, Modifier (BEM), в конечном итоге мы всегда загрязняем глобальное пространство имен, что, как мы все знаем, неправильно. Это не только неправильно в принципе, но и приводит к многочисленным ошибкам в больших кодовых базах, а в долгосрочной перспективе очень затрудняет сопровождаемость. Работая с большими командами, нетривиально узнать, был ли определенный класс или элемент уже стилизован, и большую часть "времени мы склонны добавлять новые классы вместо повторного использования существующих.

Зависимости

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

Мертвый код

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

Мертвый код - это любой код, который никогда не выполняется. Каждый разработчик сталкивается с неудобствами при удалении CSS. Потому что они не знают, на какие части сайта они влияют. Если я удалю это, это сломает сайт? Существуют инструменты, которые удаляют неиспользуемые CSS, например PurgeCSS.

Минификация

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

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

Совместное использование констант

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

Обычно мы считываем значение в клиенте, используя API JavaScript, но оптимальным решением было бы совместное использование констант и избежание дорогостоящих вычислений во время выполнения. Это пятая проблема, которую пытались решить vjeux и другие разработчики Facebook.

Недетерминированное разрешение

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

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

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

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

Изоляция

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

Предварительные и последующие процессоры

Pre & post процессоры позволяют нам использовать возможности, которых нет в vanila CSS, такие как: миксины, вложенность, переменные и т.д.

Подождите... Вы можете сказать, что в CSS у нас есть переменные, это не так, в ванильном CSS у нас есть переменные. пользовательские свойствано мы не можем использовать их как переменные. Например, мы можем использовать переменные Sass для селекторов.

• Sass / Less / Stylus и т.д.
• PostCSS

Подробнее:

• Хотите переменные CSS в объявлениях медиазапросов? Попробуйте это!
• Введение в PostCSS

Модули CSS

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

Модули CSS позволяют импортировать файл .css в объект JavaScript с определениями CSS в качестве свойств. Это также позволяет использовать свойство compose для расширения и модулизации определений стиля.

Пример

Как будут выглядеть наши стили в файле name.module.css.

Открыть Github Gist

И мы будем использовать их в нашем компоненте следующим образом:

Import css from './name.module.css'

Во время сборки нашего приложения эта конструкция будет заменена на:

Открыть Github Gist

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

Мы можем объединить Sass и CSS Modulesвместе, чтобы сделать нашу жизнь еще проще.

Подробнее:

• Что такое CSS-модули и зачем они нужны?
• Почему я перешел от стилизованных компонентов к модулям (S)CSS

Утилитарные классы

Утилитарный класс - это просто класс, который делает что-то одно. Например, класс mb-5 может означать добавление нижнего отступа в 5px. У вас будет много классов, но все они выполняют одну задачу.

Просто взглянув на HTML, вы сразу же получите представление о назначении каждого класса.

Следует помнить, что для utility-first CSS не нужна никакая библиотека, это просто методология, которая может быть применена к CSS, подобно тому, как работает BEM.

Плюсы:

• Теперь гораздо проще понять и добавить какие-либо изменения или добавить что-то новое.
• Вам не нужно будет писать новый CSS.

Минусы:

• Опыт разработчика

Открыть Github Gist

TailwindCSS

TailwindCSS Sass - это CSS-фреймворк "утилита прежде всего". Он использует совершенно иной подход, чем другие CSS-фреймворки - такие как Bootstrap или Zurb Foundation.

Tailwind CSS невероятно ориентирован на производительность и стремится создать как можно меньший файл CSS, генерируя только тот CSS, который вы действительно используете в своем проекте.

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

Он поможет вам в написании более удобного CSS.

Подобно Tailwind, есть и другие CSS-фреймворки, использующие этот подход. Среди них Basscss, Beard и turretcss.

CSS Frameworks

Главное отличие утилитарных стилей в том, что они предоставляют предварительно собранные компоненты.

Bootstrap

Проблема с CSS Frameworks, такими как Bootstrap, заключается в том, что они выглядят как сайты, созданные с помощью Bootstrap :)

Bootstrap диктует, как все должно выглядеть. И его ненавидят дизайнеры, и не зря. Мы не можем допустить, чтобы все сайты выглядели одинаково. Это нехорошо для бизнеса. И это нехорошо для бизнеса. Для административной приборной панели или внутреннего инструмента это может не быть проблемой. Но если вы создаете приложение, ориентированное на потребителя, вы, вероятно, хотите, чтобы оно больше ассоциировалось с конкретным брендом компании.

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

Библиотеки компонентов

Библиотека компонентов - это набор повторно используемых компонентов. Официальных правил, что такое библиотека компонентов, не существует.

Наиболее популярными библиотеками компонентов являются. Material UI, Chakra UI, Manine и т.д.

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

Но если вы работаете в таких продуктовых компаниях, как Netflix, Google, AirBnb и даже меньше, и вам нужен одинаковый дизайн для каждого подпроекта, вы обязательно придете к решению с помощью библиотеки компонентов. Это может быть ваша собственная или любая публичная, но настраиваемая библиотека компонентов. И это даст одно главное преимущество, которое действительно того стоит - ускорит процесс разработки. Работайте с дизайнерами, бизнес-аналитиками, разработчиками, QAs.

CSS-in-JS

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

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

Так что основная проблема подхода CSS-in-JS в том, что это не CSS.

К счастью для нас, у нас есть и другие "решения", например: linariaилиCompiled.

Заключение

Как я уже говорил ранее: Мы живем в мире "решений", но у нас нет универсального решения для каждого случая и проекта.

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