Я пишу приложения и компоненты React уже около 4 лет, и я использовал несколько «решений» стилей: CSS-модули, Glamorous, Glamour, Emotion, Styled-Components, встроенные style атрибуты и нестандартные -box import './styles.css' метод.
Все они отстой.
Отладка - отстой
Откуда, черт возьми, взялось это хешированное имя класса / атрибут данных? В некоторых библиотеках есть конфигурации или плагины веб-пакетов, которые (немного) проясняют эти имена, но вам лучше настроить их правильно, чтобы это происходило только в «dev», а не в «prod», чтобы вы не отправляли лишний вес. Вам, наверное, никогда не понадобится отлаживать производственный код, верно?
DevTools - отстой
Многие, если не большинство, библиотеки CSS-in-JS используют insertRule для добавления стилей на страницу. Несмотря на высокую производительность, этот метод имеет нежелательный побочный эффект, заключающийся в создании правил, которые нельзя редактировать в инструментах разработчика браузеров. Хотите увидеть, как выглядят небольшие изменения в ваших стилях? Лучше надеяться, что механизм Hot Module Reloading работает, потому что вы не сможете вносить изменения в код прямо в браузере.
Замок от поставщика - отстой
Ваше приложение использует react-emotion. Зависимость использует glamor. Подзависимость использует jss. Нет проблем, за исключением того, что ваше приложение теперь содержит 80 КБ JavaScript для управления тремя различными механизмами стилизации. Вы хотели попробовать новую популярность CSS-in-JS? Это будет больше, чем простая замена. API у всех разный. Иногда этого достаточно, чтобы странная ошибка стиля просачивалась в производство.
Блокировка версий отстой
Наконец-то вы присоединились к emotion. Все ваши зависимости и подчиненные зависимости были загнаны в загон и приведены в соответствие с The One True Styling Library. За исключением того, что у вас версия 9, а версия 10 только что вышла. Это так круто, но это критическое изменение версии. Затем обновится одна из ваших зависимостей. Теперь вы должны повторно загонять и снова принуждать всех к новой версии, иначе вы столкнетесь с теми же проблемами, что и vendor-lock: доставка вдвое большего количества кода (по сути) для одного движка стилизации.
Кеширование таблиц стилей - отстой
Есть небольшая ошибка стиля, которую необходимо исправить и отправить. Поскольку все стили создаются в javascript (как и создание HTML), вам необходимо сделать недействительным кеш для всего, чтобы предоставить исправление вашим пользователям. Дело не в том, что кеширование важно для работы в Интернете или пользователей, чувствительных к данным. (Если было непонятно, последняя строчка была сарказмом.)
Прогнозирование каскадов - отстой
В вашем приложении есть CSS Reset, некоторые служебные стили, некоторые глобальные общие / нормализующие стили, стили ваших компонентов и, конечно же, стили вашего приложения, которые включают несколько глобальных переопределений для одних компонентов и несколько условных переопределений для других. Чтобы избежать войны за специфичность, эти стили необходимо загружать в точном порядке. Жаль, что все это волшебным образом сделано для вас вашей библиотекой CSS-in-JS.
Загружает ли ваше приложение собственные стили до или после загрузки всех компонентов верхнего уровня? Порядок имеет значение. Ваш плагин ESLint или Prettier IDE изменил для вас импорт? Это источник вашей ошибки специфичности? Один компонент лениво загружает другой? Стили субкомпонента теперь имеют более высокий приоритет, чем стили его потребителя. Предоставляет ли ваша библиотека CSS-in-JS хоть какой-то контроль над порядком загрузки? Некоторые делают. Большинство - нет.
Перезапись стилей по умолчанию - отстой
Вы написали замечательный маленький компонент, который можно использовать везде. Каждый вариант использования будет немного отличаться, и вы уверены, что каждый потребитель захочет стилизовать его самостоятельно, но вы не хотите поставлять компонент без стиля. Вы добавляете стили по умолчанию с помощью своей любимой библиотеки CSS-in-JS. Теперь дело за потребителем, который должен бороться с этим, пока он не превратит ваш компонент в стильный продукт. В конечном итоге они пишут слишком конкретное правило и используют несколько !important объявлений. Все живут. До тех пор, пока этот более высокий компонент не будет израсходован и изменен стиль. Цикл оскорблений продолжается.
Писать производительные анимации - отстой
Возможно, вы слышали, что CSS не может изменить высоту элемента с 0 на auto. К счастью для вас, вы используете CSS-in-JS, и просто захватить высоту элемента во время рендеринга, вставить ее в правило динамического стиля и анимировать этот элемент. Вы отбрасываете проблемы производительности на задний план и хвастаетесь своим аккордеонным компонентом всем, кто будет слушать. Он настолько популярен в команде, что используется повсюду. Именно тогда вы замечаете проблемы с производительностью. Как это исправить? Может быть, заставить анимировать только одну за раз? Использовать поставщик контекста для координации всех анимаций? Не будем называть это сверх- инженерией ...
Использование библиотечных методов - отстой
У каждой библиотеки CSS-in-JS свой API и своя стратегия. Но иногда они не сильно отличаются. Ваша старая библиотека позволяла использовать литералы шаблонов? В новом нет. А как насчет объектной нотации? Ключи - это верблюжьи версии свойств CSS, верно? Как & снова используется в ключах? Что, если клавиша выбора имеет начальный пробел, например " .sub-part"? Он нацелен на потомка с этим классом? Если нет начального пробела, является ли это условным правилом для элемента, к которому оно применяется? Или он все еще нацелен на потомка?
Вы используете библиотеку, подобную стилизованным компонентам? Вы можете написать styled.div`border: 1px solid #000;`;, но что, если вам нужен элемент, который может быть либо тегом привязки , либо кнопкой? Вам нужно создать два разных компонента. Принимают ли эти сгенерированные компоненты style или className атрибуты? Как они их объединяют или упорядочивают правила? Это зависит от библиотеки и версии.
Подсветка синтаксиса - отстой
CSS с незапамятных времен имеет подсветку синтаксиса в каждой IDE. Вы не получите этого выделения при использовании CSS-in-JS, если только вы не используете методы литералов шаблона и не имеете специального плагина для своей IDE. Должно ли это быть препятствием при выборе библиотек стилей?
Добавление глобальных правил - отстой
Добавить правило в верх каскада очень просто. Слишком легко. Используйте injectGlobal(), :global { } или любой другой инструмент, который поддерживает ваша библиотека, и компонент, который вы написали, может внести правило верхнего уровня. Теперь правило влияет на все на странице. Однако ни один компонент не должен вызывать изменение стиля всего приложения. Это работа приложения! Когда следующий разработчик выискивает «ошибку», которая привела к этому правилу, он может найти только следующее:
<style id="csUI987" type="text/css"> /* offending rule */ <style>
Я предполагаю, что вы забыли добавить в плагин webpack, который оставил идентификаторы имени файла. Ой.
Заключение
Так что же не отстой? CSS. Может быть, SASS / SCSS. Вы это уже знаете. Тот новый разработчик, которого ты нанял? Она тоже это знает. То же самое и с дизайнерами, с которыми вы работаете.
В каком порядке расположен каскад? В каком порядке вы загружали файлы CSS. Никакой магии. Никакой загадки.
А как насчет определения стилей для компонентов? БЭМ. Бам.
А как насчет плавной, производительной анимации? Избегайте JS и анимируйте только opacity и transform. Или используйте JS с помощью метода FLIP или гринсока.
Как насчет создания стилей компонентов по умолчанию и включения переопределений? Поместите один класс в каждую из стилизованных частей компонента, опубликуйте или предоставьте таблицу стилей, которую потребители компонента могут загружать в правильном порядке. Тогда они смогут настроить таргетинг и переопределить нужные части. Что касается стилей, которые должны существовать для правильной работы компонента, вставьте их с помощью !important, как это делают собственные элементы в теневой модели DOM.
CSS - один из трех столпов веб-разработки. Не уклоняйся от этого и не скрывай. Это надежный язык, созданный для решения сложной проблемы стилизации для различных устройств и браузеров. Положитесь на него и изучите его, и у вас будет более успешная карьера веб-разработчика.
