Дзэн CSS
Мне кажется, что за этим будущее, но мы уже сделали это.
Сейчас модно не любить CSS. Есть много причин, почему это так, но всё сводится к следующему: CSS непредсказуем. Если у вас никогда не было опыта правки какого-либо стиля и случайного нарушения при этом всего макета, которые, вроде бы, не должны быть связаны, тогда вы либо новичок в этом, либо просто мегапрограммист, до которого нам всем как до Луны.
Так что сообщество JavaScript засучило рукава и принялось за работу. За последние пару лет произошёл Кембрийский взрыв библиотек, нацеленных на управление поведением CSS, которые все вместе принято называть CSS-in-JS.
Но мало кто догадывается, что самые большие проблемы с CSS могут быть решены без CSS-in-JS. Без нависающих проблем написание CSS не просто терпимо — это приятно. При этом не нужно бороться с дополнительными проблемами, которые приносят с собой библиотеки CSS-in-JS.
Эта статья никоим образом не предназначена для критики тяжёлой работы, проделанной сообществом CSS-in-JS. Это один из самых активных уголков экосистемы JS где каждую неделю появляются новые идеи. Вместо этого, моя цель — проиллюстрировать, почему альтернативный подход, основанный на однофайловых компонентах с настоящим CSS — чертовски восхитителен.
Самая большая проблема CSS
Всё в CSS является глобальным. Из-за этого стили, предназначенные для одной части разметки, часто затрагивают другие. Поэтому разработчики часто прибегают к диким соглашениям об именовании стилей(общих 'правил' тут нет, поскольку их очень сложно реализовать на практике), которые только повышают риск возникновения туннельного синдрома.
Гораздо хуже, когда ты работаешь в команде. Никто не решится трогать стили, созданные кем-то другим, потому что часто непонятно, что они делают, к какой разметке они применяются и какие бедствия случатся, если вы их удалите.
Следствием всего этого является, в таблицу стилей эти самые стили только добавляются. Нет никакого способа узнать, какой код можно безопасно удалить, поэтому обычно перезаписывают какой-либо существующий стиль другим, более конкретным стилем. Это встречается даже в относительно небольших проектах.
Однофайловые компоненты спасут СSS
Идея ОФК проста: вы записываете свои компоненты в HTML-файл, который (необязательно) содержит атрибуты <style> и <script>, описывающие стили и поведение компонента. Svelte, Ractive, Vue и Polymer следуют этому базовому шаблону.
В результате мы получаем несколько чудесных вещей:
- Ваши стили ограничены компонентом. Нет больше утечки, нет больше непредсказуемого каскадирования. И никаких длиннющих имён классов, придуманных для предотвращения подобных конфликтов.
- Вам не нужно больше пробираться через структуру файлов и папок, чтобы найти правила, которые нарушают вашу работу.
- Компилятор (в случае Svelte) может определять и удалять неиспользуемые стили. Нет больше постоянно растущих таблиц стилей!
Давайте посмотрим, как это выглядит на практике.
<figcaption>
Это то что подразумевают под 'использованием платформы'?
</figcaption>Каждый редактор кода уже знает CSS, так что есть большая вероятность, что вы получите автозаполнение, линтинг, подсветку синтаксиса и прочее — и всё это без дополнительных инструментов, как в случае с JS.
И поскольку это валидный CSS, мы можем использовать рабочий процесс 'подправить в devtools и вставить обратно в исходный код', без которого я лично не смог бы жить. Обратите внимание, что мы получаем карты исходников CSS из коробки, так что вы можете мгновенно определить нужные строки. Трудно переоценить эту возможность: когда вы находитесь в режиме WYSIWYG, вы не думаете с точки зрения дерева компонентов, поэтому очень важно иметь надёжный способ выяснить, откуда появились эти долбанные стили. Особенно, если это не вы изначально писали компонент. (Обещаю, это самый большой прирост производительности в вашем рабочем процессе CSS. Если вы пишете стили без карт исходников, вы почти наверняка тратите много времени. Я знаю, у меня так и было).
Для достижения ограничения области видимости Svelte немного преобразует ваши селекторы, добавляя атрибут, который одновременно применяется к затронутым элементам (хотя точный механизм не важен и может быть изменён). Он удаляет все неиспользуемые правила, затем минимизирует результат и позволяет записать его в файл .css. Есть также новая экспериментальная опция для компиляции в веб-компоненты, использующая shadow DOM для инкапсуляции стилей, если так вам больше нравится.
Это всё возможно благодаря тому, что ваш CSS анализируется (с помощью css-tree) и статически анализируется в контексте вашей разметки компонента. Статический анализ открывает двери для всех интересных возможностей в будущем — более разумных оптимизаций, подсказок, которые намного сложнее, если ваши стили вычисляются динамически во время выполнения. И это только начало.
Но мы можем добавить инструменты для работы с [x]!
Если ваша реакция на видео была 'лады, но если мы используем TypeScript и напишем плагины для каждого редактора, тогда мы сможем получить все ништяки вроде автозаполнения и подсветки синтаксиса', т.е. если вы считаете, что для достижения паритета с CSS имеет смысл создавать, документировать, продвигать и поддерживать целый зоопарк вспомогательных проектов — тогда вам с нами не по пути!
У нас нет ответов на все вопросы — пока
Нельзя не упомянуть, что CSS-in-JS решает некоторые давние вопросы:
- Как установить стили из npm?
- Как использовать константы, определённые в одном месте?
- Как вообще собирать константы в одно место?
Лично для меня, эти проблемы не перевешивают преимуществ подхода, изложенного выше. Но у вас могут быть другие приоритеты, и они могут быть достаточной вескими, чтобы отказаться от CSS.
Но в конце концов, вы всё равно должны знать CSS. Любите вы его или ненавидите — это дело десятое. Вы должны по крайней мере понимать его. У нас есть выбор: навешивать всё новые абстракции, которые делают кривую обучения веб-разработчиков ещё круче, или совместно работать над исправлением косяков в CSS. Я знаю, каким путём пойду.