Помните, когда мы делали все, используя только старый CSS? Все, что у нас было, это один файл CSS, который длился дольше, чем бессонная ночь. Ура! Тысячи и тысячи строк — обычно плохо написанных — CSS, где мы изо всех сил пытались найти единственное значение, которое нам пришлось изменить, чтобы исправить какую-то неясную и разочаровывающую ошибку IE.
Ну, эти дни позади, ребята. Работа с CSS стала интереснее и сложнее. Вероятно, последний из-за первого. И теперь, когда у нас есть CSS-препроцессоры, адаптивный веб-дизайн, прогрессивное улучшение, постепенная деградация и все остальное, о чем говорят классные дети, CSS стал более мощным, чем когда-либо.
«CSS стал более интересным и сложным».
— Мне.
Поэтому, поскольку у нас много дел, важно, чтобы мы оставались организованными. И мы, наверное, все согласны с тем, что это не всегда легко. Поэтому я подумал, что в этом посте я смогу помочь вам понять, как вы должны думать (а не как вы должны делать; я оставлю это на ваше усмотрение).
Рисование вашей архитектуры
Одним из основных преимуществ использования препроцессора CSS является возможность разбивать ваш код на несколько файлов без ущерба для производительности. Благодаря директиве Sass @import вы можете иметь столько файлов, сколько захотите, в своей среде разработки, и это скомпилируется в один файл в процессе производства.
«Несколько файлов в dev, один файл в prod.»
— Брюс Ли
Организованность начинается с правильного разделения вашего CSS на несколько файлов и папок. Как говорил один из моих учителей, «все имеет свое место, каждое место имеет свое место» . Ну вот как я люблю это делать!
Папки классные, используйте их
Папки необходимы. Дома вы не бросаете каждый лист бумаги в одну и ту же коробку. У вас, вероятно, есть папки. Один для дома / квартиры, один для банка, один для счетов и так далее.
При планировании вашей CSS-архитектуры это одно и то же: вы не просто перетаскиваете каждый файл Sass в одну и ту же папку, а классифицируете их.
Вот как мы можем организовать наши файлы:
дерзость / | | - база / | | - _reset.scss # Сбросить / нормализовать | | - _typography.scss # Правила оформления | ... # И т.д… | | - компоненты / | | - _buttons.scss # Кнопки | | - _carousel.scss # Карусель | | - _cover.scss # Обложка | | - _dropdown.scss # Выпадающий | | - _navigation.scss # Навигация | ... # И т.д… | | - помощники / | | - _variables.scss # Sass Variables | | - _functions.scss # Sass Functions | | - _mixins.scss # Sass Mixins | | - _helpers.scss # Помощники классов и заполнителей | ... # И т.д… | | - макет / | | - _grid.scss # Сетка | | - _header.scss # Заголовок | | - _footer.scss # Нижний колонтитул | | - _sidebar.scss # Боковая панель | | - _forms.scss # Формы | ... # И т.д… | | - страницы / | | - _home.scss # Домашние стили | | - _contact.scss # Связаться с конкретными стилями | ... # И т.д… | | - темы / | | - _theme.scss # Тема по умолчанию | | - _admin.scss # Административная тема | ... # И т.д… | | - продавцы / | | - _bootstrap.scss # Bootstrap | | - _jquery-ui.scss # jQuery UI | ... # И т.д… | | `- main.scss # основной файл Sass
Как видите, на корневом уровне есть только один файл Sass: main.scss . Все остальные файлы разделены на соответствующие папки и имеют префикс подчеркивания ( _ ), чтобы сообщить Sass, что они являются частичными файлами .scss, которые не следует компилировать в файлы .css . Действительно, это роль базового файла для импорта и объединения всех этих файлов .
«Один файл, чтобы управлять ими всеми,
Один файл, чтобы найти их,
Один файл, чтобы привести их всех,
И нахальный способ объединить их.
— JRR Tolkien
Давайте теперь посмотрим на каждую из папок в нашей архитектуре.
База
base/ папка содержит то, что мы могли бы назвать шаблонным материалом для вашего проекта. Там вы можете найти сброс (или Normalize.css, или что-то еще), возможно, некоторые вещи, связанные с типографикой, и, в зависимости от проекта, возможно, некоторые другие файлы.
-
_reset.scssили_normalize.scss -
_typography.scss
Помощники
Папка helpers/ (иногда называемая utils/ ) собирает все инструменты и помощники Sass, которые мы будем использовать в проекте. Есть функция? Миксин? Поместите это туда. Эта папка также содержит файл _variables.scss (иногда _config.scss ), в котором хранятся все глобальные переменные для проекта (для типографики, цветовых схем и т. Д.).
-
_variables.scss -
_mixins.scss -
_functions.scss -
_placeholders.scss(часто называется_helpers.scss)
раскладка
Каталог layout/ (иногда называемый partials/ ) обычно содержит несколько файлов, каждый из которых задает некоторые стили для основных разделов макета (заголовок, нижний колонтитул и т. Д.). Он также содержит файл _grid который является системой сетки, используемой для построения макета.
-
_grid.scss -
_header.scss -
_footer.scss -
_sidebar.scss -
_forms.scss
Наличие навигационного файла ( _navigation.scss ) в этой папке может иметь смысл, хотя я использую его для _navigation.scss в components/ (см. Следующий раздел). Я думаю, что было бы лучше в папке /layout но я позволю вам решить.
Компоненты
Для более мелких компонентов есть папка components/ (часто называемая modules/ ). Хотя layout/ является своего рода макросом (определяющим глобальный каркас), components/ более микро . Он может содержать все виды специальных модулей, таких как слайдер, загрузчик, виджет или что-то в этом роде. В компонентах обычно много файлов, так как ваш сайт является должен состоять в основном из крошечных модулей.
-
_media.scss -
_carousel.scss -
_thumbnails.scss
страницы
Если у вас есть стили для конкретной страницы, я думаю, что было бы здорово поместить их в pages/ папку и в файл, названный в честь страницы. Например, весьма часто иметь очень специфические стили для домашней страницы, поэтому у вас будет файл _home.scss на pages/ с этим _home.scss .
-
_home.scss -
_contact.scss
В зависимости от процесса развертывания эти файлы можно вызывать самостоятельно, чтобы избежать их слияния с другими в итоговой таблице стилей. Это действительно зависит от вас. Там, где я работаю, мы решили сделать их не частичными, чтобы включать их только на страницах, где они требуются. Например, наша домашняя страница имеет очень специфический макет, составляя около 200 строк CSS. Чтобы эти правила не загружались на каждой странице, мы включаем этот файл только на главной странице.
Темы
Если вы работаете на большом сайте с несколькими темами, как я, то иметь смысл иметь папку themes/ . Вы можете добавить туда все стили, связанные с темой / дизайном. Это определенно зависит от проекта, поэтому обязательно включайте его, только если вы чувствуете необходимость.
-
_theme.scss -
_admin.scss
Вендоры
И последнее, но не менее важное: у вас, вероятно, будет папка vendors vendors/ содержащая все файлы CSS из внешних библиотек и сред — Bootstrap, jQueryUI, FancyCarouselSliderjQueryPowered и т. Д. Хранить их в одной папке — хороший способ сказать: «Эй, это не от меня, не от моего кода, не от моей ответственности».
Пример:
-
bootstrap.scss -
jquery-ui.scss -
select2.scss
Кроме того, где я работаю, у нас также есть папка vendors-extensions/ которой мы храним файлы, которые переопределяют некоторые мелкие фрагменты от поставщиков. Например, у нас есть файл _bootstrap.scss который мы можем использовать для изменения некоторых компонентов в Bootstrap. Это делается для того, чтобы избежать редактирования самих файлов поставщика, что, как правило, не очень хорошая идея.
Вот и все. Эта архитектура может варьироваться в зависимости от проекта, но я уверен, что вы поняли концепцию. При вложении папок в папки я не всегда советую против этого, но я не предпочитаю это. Я обнаружил, что в большинстве случаев одного уровня архитектуры более чем достаточно, чтобы поддерживать чистоту и организованность без особой сложности. Но если вы думаете, что ваш проект заслуживает более глубокой структуры, не стесняйтесь делать это.
Совет для профессионалов: если вы чувствуете, что ваша архитектура не очевидна для тех, кто открывает папку scss , вы можете рассмотреть возможность добавления файла README.md на корневом уровне (рядом с main.scss ), объясняющего все.
Файлы тоже классные!
Мне часто задают вопрос: «Сколько файлов — это слишком много файлов?», И на это я отвечаю: файлов никогда не бывает слишком много. Разделение вашей работы на несколько файлов имеет целью помочь вам организовать ваш код. Если вы чувствуете, что что-то заслуживает того, чтобы разделить его на множество файлов, смело сходите с ума! Как говорит Крис Койер в своем руководстве по стилю Sass :
«Разбейте столько маленьких файлов, сколько имеет смысл».
— Крис Койер
Тем не менее, я бы посоветовал не разбивать один компонент на несколько файлов, если у вас нет веских причин для этого. Обычно у меня есть один модуль на файл — не больше, не меньше — с чистым именем, таким как имя модуля, которое он обозначает. Таким образом, я могу быстро перейти к «возвышенному» тексту, когда что-то ищу.
В итоге
Все предложения, представленные в этой статье, основаны на моем личном опыте работы в качестве единственного фронт-разработчика в сетевом отделении Crédit Agricole, огромной банковской группы во Франции. Ваши собственные обстоятельства и опыт могут потребовать другого подхода.
Если бы мы могли выбрать золотое правило для разработки проекта Sass, это могло бы быть так просто: выбрать что-то, что имеет смысл. Если вы работаете как команда на внешнем интерфейсе, убедитесь, что все чувствуют себя комфортно с выбранной структурой, иначе выпустите документацию где-нибудь, чтобы каждый мог понять, что происходит.
Есть ли у вас какие-либо мысли или предложения по архитектуре Sass? Мы будем рады услышать ваши комментарии.
«С большой властью приходит большая ответственность.»
— Аквамен
Эта статья также доступна на корейском языке в Интернете .