CSS-модули
Какими CSS обладает особенностями, которые приносят боль на больших проектах?
- глобальное пространство имен
- разрешение зависимостей
- поиск «мертвого» кода
- отсутствие констант
- неоднозначный результат (каскад)
Возьмем простой пример: кнопка и ее состояния.
В реальности
Учитывая, что пространство имен глобальное, приходится вводить определенные соглашения по именованию классов, чтобы избежать случайных пересечений.
В БЭМ-нотации это бы выглядело так:
.button .button_state_disabled .button_state_error .button_state_progress
Я думаю, что многие согласятся с тем, что при первом знакомстве с БЭМ когнитивный диссонанс вызывают огромные названия классов, которые получаются в итоге.
Естественно было бы написать:
Однако, через месяц, когда все забудут про это место, появится класс .disabled в другом файле(который будет означать совсем другое), а здесь неожиданно сломается — пространство имен единое.
Можно было бы написать так:
Но тогда получается слишком много дублирования кода, потому что кнопки отличаются всего одним стилем: .button-disabled должен содержать все то же, что и .button, но, например, другой цвет фона.
Сейча эта задача решается с использованием миксинов на уровне препроцессоров, потому что в CSS нет такой возможности.
В идеальном мире
Все селекторы локальные в рамках конкретного файла.
Это означает, что в файле button.css, я пишу:
А мой коллега в недрах совсем другого компонента:
Нет пересечений для .text — нет необходимости в специальных классах для элементов блоков.
Локальное пространство имен справедливо так же для так же для анимаций, объявленных через @keyframes.
В шаблоне не хочется думать про композицию классов вида .button.button_state_disabled для получения определенного состояния.
Чтобы этого избежать, каждый класс должен содержать в себе все необходимое для отрисовки каждого состояния компонента:
Ключевое слово composes дает мне функционал миксинов.
Причем я могу попросить стили из другого файла, что дает мне модульность на уровне CSS.
Реальность или вымысел
Выглядит неплохо. Что нужно для реализации такого интерфейса? Очевидно, необходимо установить связь между шаблонами и CSS.
Все зависит от того, какой шаблонизатор используется. В современном фронтенде практически все шаблонизаторы — javascript-приложения, задача которых превратить шаблоны в html.
Представим, что у нас есть простой шаблонизатор, который умеет только интерполяцию строк:
Весь CSS экспортируется как объект, ключами которого являются понятные, семантичные, имена классов для использования в шаблоне, а значениями — те имена классов, которые будут в итоговой разметке (например, уникальные хеши).
Сейчас это можно сделать с помощью плагина для webpack или плагина для browserify.
Более современный, реальный пример — в шаблоне reactjs-компонента:
import < Component >from 'react'; import styles from './button.css'; export default class button extends Component < render() < let className = styles.button let text = "Отправить заявку" if (this.state.loading) < className = styles.buttonDisabled >return > > > Что почитать
Кажется, видимая движуха началась с доклада «CSS in JS»
Статья CSS-модули: добро пожаловать в будущее. Прежде, чем читать, откройте исходный код, посмотрите на скомпилированные названия классов: красота! 🙂
Организация на гитхабе, где ребята штурмуют тему модульности в CSS. Здесь документация: примеры, концепции и конкретные инструменты: postcss, browserify и webpack плагины.
Что такое CSS-модули и зачем они нам?
В последнее время меня интригуют CSS-модули. Если вы о них не слышали — эта статья для вас. Мы рассмотрим, что это за проект, какие задачи он решает и каковы причины его возникновения. Если вы тоже заинтриговались — не переключайтесь, следующая статья будет о том, как начать их применять. А если вас интересует внедрение в проект или более продвинутое использование CSS-модулей, третья статья в этой серии будет о том, как использовать их c React.
Серия статей
Часть 1: Что такое CSS-модули и зачем они нам? (Вы её читаете!)
Что такое CSS-модули?
Согласно определению из репозитория, CSS-модули — это:
CSS-файлы, в которых все классы и анимации по умолчанию находятся в локальной области видимости.
CSS-модули — это не официальная спецификация, они не имплементированы в браузеры, скорее, это задача, запускаемая на стадии сборки проекта (например, с помощью Webpack или Browserify), в процессе выполнения которой имена классов и селекторы изменяются так, чтобы образовалась своего рода локальная область видимости (что-то вроде пространства имен).
Как это выглядит и зачем нам это? Сейчас расскажу. Во-первых, вспомните как обычно работают HTML и CSS. Класс прописывается в HTML:
h1 class="title">Пример заголовка h1> .title < background-color: red; > Пока CSS применяется к HTML-документу, фон будет красным. Нам не нужно как-то обрабатывать CSS или HTML, оба формата понятны браузеру.
CSS-модули используют другой подход. Вместо того, чтобы писать обычный HTML, нам придётся написать разметку в JavaScript-файле, например, в index.js . Вот как это может выглядеть (ниже мы рассмотрим более реальные примеры):
import styles from "./styles.css"; element.innerHTML = `$ "> Пример заголовка `
; В процессе сборки компилятор проанализирует styles.css , который мы импортировали, потом проанализирует JavaScript и сделает класс .title доступным через styles.title . Затем сгенерирует на их основе новые HTML и CSS-файлы, уже с новыми классами.
Сгенерированный HTML может выглядеть следующим образом:
h1 class="_styles__title_309571057"> Пример заголовка h1> А вот так может выглядеть CSS:
._styles__title_309571057 < background-color: red; > 
Значение атрибута class и селектор .title заменены на новые. Исходный CSS в браузер вообще не попадает.
Как сказал Хьюго Жироде́ль (Hugo Giraduel) в своей статье по этому поводу:
[классы] генерируются автоматически, они уникальны и привязаны к исходным стилям.
Вот это и называется поместить стили в локальную область видимости. Они находятся в области видимости определенного шаблона. Если у нас есть файл buttons.css , он будет импортирован только в шаблон buttons.js , и класс .btn , который он содержит, будет недоступен для других шаблонов (например, forms.js ), пока мы не импортируем его и туда тоже.
Зачем нам устраивать всю эту канитель с CSS и HTML? Зачем нам это вообще сдалось, ради всего святого?!
Зачем нам нужно использовать CSS-модули?
CSS-модули гарантируют, что все стили одного компонента:
Кроме того, каждый компонент может иметь настоящие зависимости, например:
import buttons from "./buttons.css"; import padding from "./padding.css"; element.innerHTML = `$ $ ">`; Этот подход был разработан, что бы решить проблему глобальной области видимости в CSS
Вы когда-нибудь испытывали соблазн в условиях нехватки времени или ресурсов просто писать CSS так быстро, как можете, не думая о последствиях?
Пихали ли в конец таблицы стилей какой-нибудь мусор, собираясь потом его отрефакторить, и так никогда этого и не сделали?
Бывало ли такое, что вы просматривали стили, не до конца понимая что они делают и используются ли они вообще?
Задумывались ли вы, получится ли избавиться от некоторых стилей, ничего при этом не сломав? Не приходилось ли гадать, эти стили работают сами по себе или зависят от других? Случалось ли вам перезаписывать стили?
Это вопросы, которые могут привести к серьезной головной боли, пропущенным дедлайнам и грустным взглядам в окно.
С CSS-модулями и концепцией использования локальной области видимости по умолчанию таких проблем можно избежать. Вам всегда приходится думать о последствиях, когда вы пишите стили.
Например, если вы используете в HTML класс random-gross-class , не обработав его как класс CSS-модуля, стили не применятся, так как CSS-селектор превратится во что-то вроде ._style_random-gross-class_0038089 .
Ключевое слово composes
Допустим, у нас есть модуль под названием type.css , содержащий стили для текста. В этом файле может быть, например, такое:
.serif-font < font-family: Georgia, serif; > .display < composes: serif-font; font-size: 30px; line-height: 35px; > Один из этих классов мы используем в шаблоне:
import type from "./type.css"; element.innerHTML = `$ "> Пример заголовка `
; В результате получится такая разметка:
h1 class="_type__display_0980340 _type__serif_404840"> Пример заголовка h1> Оба класса связаны с элементом через использование ключевого слова composes , решая таким образом некоторые проблемы, которые есть в похожих решениях, например в @extend Sass.
Так можно даже подставлять данные из отдельного CSS-файла:
.element < composes: dark-red from "./colors.css"; font-size: 30px; line-height: 1.2; > БЭМ не нужен
Нам не нужен БЭМ, если мы используем CSS-модули. По двум причинам:
- Простота чтения. Код вроде type.display так же понятен для разработчика, как и .font-size__serif—large из БЭМ. Его даже проще читать, чем разросшиеся БЭМ-селекторы.
- Локальная область видимости. Допустим, в одном из модулей у нас есть класс .big и он увеличивает font-size на некоторую величину. В другом модуле у нас есть точно такой же класс .big , который увеличивает padding и font-size на другую величину. И это не имеет никакого значения! Они не будут конфликтовать, так как у стилей различаются области видимости. Даже если модуль импортирует обе таблицы стилей, у классов будет своё уникальное имя, созданное в процессе сборки специально для них. Другими словами, при использовании CSS-модулей проблемы специфичности селекторов просто исчезают.
И это только некоторые из достоинств использования CSS-модулей.
Если вам интересно узнать больше, Глен Маден (Glen Madden) много пишет на эту тему.
В следующей статье из этой серии мы рассмотрим как поднять проект используя Webpack и CSS-модули. Мы будем использовать для этого новейшие возможности ES2015 и рассмотрим в процессе несколько примеров, чтобы в полной мере разобраться в происходящем.