Дзэн 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) может определять и удалять неиспользуемые стили. Нет больше постоянно растущих таблиц стилей!
Давайте посмотрим, как это выглядит на практике.
Каждый редактор кода уже знает CSS, так что есть большая вероятность, что вы получите автозаполнение, линтинг, подсветку синтаксиса и прочее — и всё это без дополнительных инструментов, как в случае с JS.
И поскольку это валидный CSS, мы можем использовать рабочий процесс 'подправить в devtools и вставить обратно в исходный код', без которого я лично не смог бы жить. Обратите внимание, что мы получаем карты исходников CSS из коробки, так что вы можете мгновенно определить нужные строки. Трудно переоценить эту возможность: когда вы находитесь в режиме WYSIWYG, вы не думаете с точки зрения дерева компонентов, поэтому очень важно иметь надёжный способ выяснить, откуда появились эти долбанные стили. Особенно, если это не вы изначально писали компонент. (Обещаю, это самый большой прирост производительности в вашем рабочем процессе CSS. Если вы пишете стили без карт исходников, вы почти наверняка тратите много времени. Я знаю, у меня так и было).
Для достижения ограничения области видимости Svelte немного преобразует ваши селекторы, добавляя атрибут, который одновременно применяется к затронутым элементам (хотя точный механизм не важен и может быть изменён). Он удаляет все неиспользуемые правила, затем минимизирует результат и позволяет записать его в файл .css. Есть также новая экспериментальная опция для компиляции в веб-компоненты, использующая shadow DOM для инкапсуляции стилей, если так вам больше нравится.
Это всё возможно благодаря тому, что ваш CSS анализируется (с помощью css-tree) и статически анализируется в контексте вашей разметки компонента. Статический анализ открывает двери для всех интересных возможностей в будущем — более разумных оптимизаций, подсказок, которые намного сложнее, если ваши стили вычисляются динамически во время выполнения. И это только начало.
Но мы можем добавить инструменты для работы с [x]!
Если ваша реакция на видео была 'лады, но если мы используем TypeScript и напишем плагины для каждого редактора, тогда мы сможем получить все ништяки вроде автозаполнения и подсветки синтаксиса', т.е. если вы считаете, что для достижения паритета с CSS имеет смысл создавать, документировать, продвигать и поддерживать целый зоопарк вспомогательных проектов — тогда вам с нами не по пути!
У нас нет ответов на все вопросы — пока
Нельзя не упомянуть, что CSS-in-JS решает некоторые давние вопросы:
- Как установить стили из npm?
- Как использовать константы, определённые в одном месте?
- Как вообще собирать константы в одно место?
Лично для меня, эти проблемы не перевешивают преимуществ подхода, изложенного выше. Но у вас могут быть другие приоритеты, и они могут быть достаточной вескими, чтобы отказаться от CSS.
Но в конце концов, вы всё равно должны знать CSS. Любите вы его или ненавидите — это дело десятое. Вы должны по крайней мере понимать его. У нас есть выбор: навешивать всё новые абстракции, которые делают кривую обучения веб-разработчиков ещё круче, или совместно работать над исправлением косяков в CSS. Я знаю, каким путём пойду.