Почему вам не стоит использовать Styled
common issue example for css-in-js
Пролог
Технология css-in-js существует уже довольно давно. Ещё в начале своего профессионального опыта я встречал подходы, в которых стайлинг локальных частей интерфейса пробрасывался в html через javascript в виде css директив. Иногда это необходимая мера, хотя необходимой она случается изредка, но раз в год, как говорится, и палка стреляет. У меня на опыте был пример построения раздела интерфейса, в котором устанавливаемое на сайт пользователя модальное окно можно рестайлить через кодовый редактор с live preview. css-in-js бывает оправдан, поэтому хочу сразу оговориться — хоронить никакой подход не стоит. Но и идеализировать его как универсальную пилюлю тоже не надо. Рендер стилей, привязанный к логике рендера компонентов в контексте всего проекта — это просто свой путь со своими приключениями, появившийся на мой взгляд в общей психопатии привязывать к state всё что только можно. Что если посмотреть — откуда взялась эта техногогия? На сегодняшний день на рынке проектирования интерфейсов сложился монополист react, диктующий программистам свои правила игры, и который даже без использования styled модуля имеет в себе простейщую инверсию управления cssInJs.
React — важный персонаж в этой теме. Он, словно useEffect всего современного front-end — стал центром силы, средоточием зла в виде голого state management, не предусматривающего из коробки ничего иного.
Редкий кадр — Шина событий под React.
Ничего подобного в каком-то более менее продуманном решении в npm я не нашёл.
А что там у остальных?
Возьмём ближайшего к react лидера серьёзного интерпрайза — angular. Их разработчики по большей части до сих пор предпочитают использовать sass с голыми методологиями (SMACSS/BEM) и для них cssInJs и передача управления значениями стилей остаётся на уровне экспериментов.
Свои цифры производительности
Проводить свои опыты по измерению скорости инициализации бандла и исполнения его отдельных функций я в этой статье не стану, во-первых потому что мне лень, а во-вторых потому что это уже сделали за меня. С последней ссылкой очень рекомендую ознакомиться всем разработчикам, хайпящим на syled словно на мане небесной.
вес бандла сократил? мммолодец!
На самом деле толком и измерять ничего не надо чтобы понять, что стайлинг, плотно вплетённый в react займёт часть памяти в VirtualDOM и отнимет часть процессорного времени на все хуки жизненного цикла для обновления своих директив согласно актуальному state. Тут как раз таки cssInJs противопоставляет себя precompiled css, при чём не в лучщем свете. Ведь одно дело если реакт отрендерил в элемент класс и уже лежащие в памяти стили привязались к элементу, а совсем другое, если реакт отрендерил стили элемента, отрендерил класс, браузер инициировал стили и стили привязались к элементу.
Производительность бандла, падающего пользователю в браузер — не единственные страдающие цифры. Скоростью сборки и обновления в рантайме разработки тоже приходится жертвовать, особенно если в связке со styled используется typescript (за исключением последней версии без polling подхода при перепроверке кода).
Моё отношение к styled
Для начала хочу отметить в styled модуле наличие createGlobalStyles. И оно немудрено — одними локальными стилями компонентов сыт не будешь. А если учесть что стили плотно привязаны к жизненному циклу компонентов — держать в них глобальные стили — плохая идея. Приведённая выше функция решает эту проблему, но всё таки выбивается из композиции из-за чего лично мной воспринимается как костыль.
Выводы
Если вас сильно раздражают выбивающиеся из общей картины стилей необходимые вставки директив из javascript, к примеру если цвета с сервера приходят и применяются на элементы, итп. И у вас в проекте такого веселья много — styled для таки проектов подходит идеально. Если же в проекте весь стайлинг изначально известен, нет никаких подобных извращений — я выберу SASS.
Но по какому бы пути я ни пошёл — дай мне только волю — я и туда и сюда вкручу tailwind =)
