Хабрахабр

О преимуществах встраивания CSS в JS

Автор оригинала, Сунил Пай, является автором относительно популярной библиотеки glamor и работает разработчиком в Facebook. Этот пост является развернутым ответом на вопросы из этого разговора в Твиттере.

Как написание CSS внутри JS делает его более поддерживаемым? Каким образом Javascript оказывается более удобным чем CSS?

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

Наибольшее преимущество cij состоит в том, что компьютеры могут генерировать эти селекторы автоматически. Итак, самое главное в CSS-in-JS (cij) это CSS-селекторы. в принципе хороши, но они основываются на вручную написанных селекторах, которым сложно обеспечить уникальность в общем пространстве имен, потому что там всегда есть шанс на пересечение. Конвенции типа OOCSS и т.п. Эта ситуация усугубляется с использованием сторонних библиотек. Если не случится сейчас, то может произойти спустя года три, когда ваша команда разрастется, а обстоятельства поменяются. Ограничение области действия CSS-селекторов также может достигаться использованием CSS-модулей, которые пользуются популярностью именно за эту возможность.

Мы должны пользоваться помощью компьютеров и не рассчитывать на безупречность и безошибочность людей (потому что это не так). Тем не менее при всех этих подходах селекторы очень сложно статически анализировать и находить, какие из них сломаны (или содержат опечатки), а это означает что их придется проверять вручную в процессе code-review, что снизит эффективность команды. CSS-in-JS дает возможность автоматизировать генерацию уникальных селекторов и идентификаторов.

Например, мы можем элементарно реализовать извлечение критического CSS, сопоставляя блоки HTML с нужными им стилями, так что мы сможем загрузить на страницу всего 1-2 Кб CSS, который нужен для изначального отображения страницы. Кроме того, усиленный контроль за CSS-селекторами открывает новые возможности, которые не были легко доступны раньше. Фреймворки типа Gatsby и Next активно этим пользуются, чтобы улучшить показатели производительности в проектах на их основе. Безо всякого рантайма! Это значительно сокращает время первоначальной отрисовки страницы. Они встраивают критический CSS прямо в загружаемый HTML просто потому что он весит настолько мало, что это будет лучше лишнего запроса, блокирующего загрузку страницы. Выгода приходит от применения критического CSS, а также использования динамического import(), разделения кода и удалению неиспользуемого кода. Более того, это также способствует решению проблем размера загружаемого Javascript! Здесь есть немного аналитики на эту тему.) (В противовес постоянно растущим легаси файлам стилей, в которые разработчики только добавляют новый код, боясь трогать существующий.

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

(Я написал здесь об этом подробнее, и – если я правильно понимаю – это единственная библиотека, которая добилась этого). В самом деле, вам это понравится: вы сможете, наконец, по-честному использовать CSS-переменные во всех браузерах, то есть нативные возможности без рантайма в браузерах, которые их поддерживают, и специальный рантайм для старых браузеров.

Например, у вас есть элемент с class=“a b”, но классы a и b определены в разных файлах стилей, то вы не сможете быть уверены в финальном виде блока, если у вас не задан четко порядок следования файлов стилей. В ситуации сложных SPA с кучей компонентов и асинхронной загрузкой ресурсов, таких как скрипты и стили, вы не можете гарантировать точный порядок загрузки стилей, так что либо вам придется создавать какие-то рантайм решения для гарантирования порядка стилей, или просто использовать !important, даже если вы придерживаетесь какой-то CSS-методологии. Кодовая база Facebook содержит тысячи использований !important, даже несмотря на то, что код писался квалифицированными программистами с использованием принципов SOLID и хорошим взаимодействием с командой дизайнеров.

Но мы не застряли там навсегда – сейчас мы используем модули, и системы сборки сшивают их вместе в гарантированно правильном порядке. Здесь часто говорится об обращение с CSS как будто это Javascript – учитывая, что 10 лет назад мы уже решали аналогичные проблемы для JS – библиотеки и модули регистрировали себя в глобальное пространство имен ($ и тому подобные) и нам приходилось быть довольно внимательными с порядком подключение скриптов в HTML. Это происходит просто и прозрачно для нас.

Я придерживаюсь такого подхода и он работает для меня хорошо. Наблюдая за реальными проектами, я также заметил, что вы все еще можете использовать традиционные архитектурные подходы (типа OOCSS или SMACSS и т.п.) в мире CSS-in-JS – элементы тех архитектур представляются здесь JS-объектами, вместо блоков селектор+стили. Здесь об этом можно почитать больше.

В самом деле, именно поэтому здесь нет какой то одной "каноничной" библиотеки, которая представляет CSS-in-JS – это спектр разных решений, от ванильного статического CSS с одной стороны до полностью динамических библиотек, типа styled-components с другой. Также я хорошо осведомлен о недостатках CSS-in-JS. Каждая из этих библиотек имеет свои недостатки – некоторые занимаются извлечением стилей на этапе сборки, чтобы не было расходов в рантайме, некоторые сфокусированы на правильности или удобстве для разработчиков, другие заточены на эффективную реализацию сложных анимаций, и так далее и тому подобное. Препроцессоры типа SASS или LESS могут показаться перпендикулярными этому спектру, потому что они теоретически могут использоваться любой из этих библиотек на усмотрение их авторов. И это происходит не только с библиотеками – разработчики веб-стандартов (ShadowDOM и других) доблестно стараются решить эти проблемы тоже, но их решение также имеет недостатки, наименьший из которых, это то что они пока не везде доступны, что делает это неприемлемым для использования во множестве команд. Это многообразие – естественная реакция на необходимость разных решений для разных рабочих задач, в чересчур быстро развивающийся индустрии.

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

S. P. Ссылка на оригинал. Слишком поздно осознал, что забыл отметить галочку "Перевод", поэтому опубликовалось вот так.

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

Теги
Показать больше

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть