От автора: в последнее время мной была выполнена проверка CSS в огромном объеме, и я подумал, что было бы неплохо записать, как я это делаю. Уверен, что есть миллион различных способов сделать это в зависимости от размера и масштаба вашего приложения и того, как CSS работает под капотом, поэтому, пожалуйста, отнеситесь к этому с определенной долей скептицизма.
Сначала несколько замечаний: в Gusto, компании, в которой я работаю сегодня, наши инженеры и дизайнеры пишут на Sass и используют веб-пакеты для компиляции этих файлов в CSS. Наша производственная среда сводит весь этот код в один файл CSS. Тем не менее, наш CSS состоит из трех отдельных доменов. Поэтому я загрузил их все на свой компьютер, потому что хотел проверить их по отдельности. Вот что делают эти файлы:
manifest.css: файл, который генерируется из всех наших функций Sass, миксинов и содержит все стандартные стили HTML и служебные классы.
components.css: файл, который состоит из компонентов React, таких как Button.scss, Card.scss и т. д. Он и manifest.css происходят из репозитория библиотеки компонентов и импортируются в основное приложение.
app.css: коллекция стилей, которые переопределяют компоненты и манифест. Сегодня он существует в нашем основном репо-приложении.
После того, как я загрузил все, я забросил их в S3 и пропустил через CSS Stats. (Я не смог найти инструмент командной строки, который мне понравился бы, поэтому решил остаться на этом инструменте.) Самое лучшее в CSS Stats — это то, что он дает массу информации о состоянии и качестве CSS сайта, и, соответственно, о системе дизайна. Это достигается путем отображения количества уникальных объявлений CSS font-size и уникальных background-color, а также графика специфичности для этого конкретного файла CSS.
Сначала я хотел лучше понять файл manifest.css. Как я уже упоминал, этот файл содержит все служебные классы (такие как padding-top-10px и c-salt-500), а также файлы нормализации и сброса CSS, поэтому он довольно фундаментален для всего остального. Я начал копаться в результатах.
Здесь есть некоторые очевидные проблемы, такие как наличие 101 уникального цвета и 115 уникальных цветов фона. Почему это так важно? Что ж, это немного поразительно для меня, потому что наша команда уже собрала набор функций Sass для вывода очень определенного количества цветов. В нашем Figma UI Kit и variables_color.scss (который компилируется в файл манифеста) мы объявляем в общей сложности 68 уникальных цветов:
Итак, откуда взялись все эти дополнительные цвета? Ну, я предполагаю, что они приходят из Bootstrap. Ранее, когда мы начинали создавать приложение, мы в спешне строили его основе стилей Bootstrap, не прибегая к рефакторингу. Был определенный момент, когда мы обнаружили визуальные несоответствия в нашем приложении, были написаны сотни строк кода, которые просто переопределяли Bootstrap. Довольно смело я удалил CSS из Bootstrap нашего основного приложения и заархивировал его внутри manifest.css, ожидая того дня, когда мы сможем вернуться к нему и провести его рефакторинг.
Эти дополнительные цвета, вероятно, взяты из этого старого файла Bootstrap, но, возможно, стоит изучить это подробнее. В любом случае, реальная проблема для меня заключается в том, что мое понимание системы проектирования отличается от того, что есть во front-end. Это большая проблема! Если мое понимание системы дизайна отличается от того, как работает CSS, то инженеры и дизайнеры могут неправильно понять шаблоны и создать путаницу, которая распространится по всей организации. Подумайте о раздутии кода и сложностях с отладкой, не говоря уже о других последствиях.
Я читал, «Для кого предназначены системы проектирования?» Мэтью Стрёма, и мне очень понравилось, когда он цитирует доклад Джули Энн-Хорват, в котором она отмечает, что «система дизайна не существует, пока она не запущена в производство». Следуя этой логике, становится понятно, что система дизайна, которую я продумал, но которую мы не реализовали, на самом деле не существует.
Возвращаясь к следующему manifest.css: график специфичности для этого файла должен быть плавным, и все же есть некоторые явные скачки, которые показывают, что там, вероятно, немного больше CSS, который необходимо реорганизовать:
Следующим у нас идет components.css. Помните, что это файл, из которого происходят стили для наших компонентов, поэтому я заранее подумал, что он должен быть немного более грязным, чем файл манифеста. Введя его в CSS Stats, я получил следующее.
Статистика CSS показывает похожие проблемы — например, слишком много размеров шрифтов (что вообще происходит с таким гигантским размером шрифта?) — но есть также слишком много пользовательских цветов и цветов фона. Я уже догадывался о том, какая основная проблема с этим файлом CSS, еще до того, как начал анализ, и я подозревал, что эту проблему вообще не покажут эти данные. Позвольте мне объяснить.
Большое количество компонентов были файлами Bootstrap того или иного типа. Возьмем к примеру наш компонент React Accordion.jsx. Он импортирует файл accordion.css, который затем компилируется со всеми CSS других компонентов в файл components.css. Проблема в том, что некоторые стили Accordion влияют не только на этот компонент. CSS из этого файла сливается с другими шаблонами и классами, которые не привязаны только к одному компоненту. Это похоже на яд для нашей системы, и это влияет на нашу команду, потому что это затрудняет надежное внесение изменений в один компонент. Это также делает уязвимой нашу базу кода.
Поэтому я говорю, что такие инструменты, как CSS Stats, являются удивительными, они помогают проверять основные показатели CSS, но я не думаю, что они когда-либо действительно позволят нам получить полную картину. В любом случае следующий файл app.css.
Это «глыба» — кодовая база, которую в настоящее время наша команда разработчиков пытается лучше понять и, как мы надеемся, преобразовать в ряд гибких и поддерживаемых компонентов React, которые другие люди смогут повторно использовать.
Что меня беспокоит в этой кодовой базе, так это специфика всего, что происходит, когда что-то меняется в manifest.css или в components.css? Будут ли эти стили переопределены? Что будет с красивыми и аккуратными стилями компонентов, которые мы импортируем в новый проект?
Я не знаю, где я это подхватил, но в последнее время я очень часто говорю — вы всегда должны быть в состоянии предсказать, что собирается делать ваш CSS, будь то отдельная строка кода или гигантская кодовая база смешанных стилей. В этом суть систем дизайна — проектирование и создание предсказуемых интерфейсов для будущего. И если в нашем скомпилированном CSS есть все эти непредсказуемые части, то нам нужно собрать их вместе, чтобы это исправить.
В любом случае, после всего этого я бросил некоторые данные в документ Dropbox Paper, чтобы убедиться, что мы приступим к решению этих проблем и увидим постепенное улучшение со временем. Это выглядит сегодня примерно так:
Как вы выполняете аудит CSS? Выполняет ли ваша команда проверку CSS? Есть ли у вас приемы и советы, которыми вы бы хотели поделиться? Оставьте комментарий ниже!
Автор: Robin Rendle
Источник: https://css-tricks.com/
Редакция: Команда webformyself.