Стратегия папок
Введение
Большая часть этой статьи посвящена стратегиям, которые мы можем применить для использования папок пользовательских классов.
Все проекты не похожи друг на друга.
- Проекты имеют различные требования.
- Проекты отличаются по дизайну и компоновке.
- Проекты могут иметь различные варианты поддержки после передачи заказчику.
Эти факторы могут влиять на нашу стратегию именования папок для проекта.
Папки были созданы для того, чтобы помочь нам гибко именовать и организовывать классы. Не забывайте, что "Client-First" - это "Единое соглашение об именовании для любых проектов". Для этого нам и нужна гибкость в системе организации папок.
Не существует правильных или неправильных наименований классов. Есть только более эффективные и менее эффективные.
Высокая эффективность работы в Webflow достигается тогда, когда наша стратегия разработки адаптирована под проект, который мы создаем.
Ниже мы показываем множество различных стратегий в именовании классов с различными стилями организации папок.
Важно понимать, что мы не должны использовать все стратегии в одном проекте. Мы можем использовать несколько стратегий, но не стоит пытаться использовать сразу все.
При внедрении нашей системы папок необходимо принять единое соглашение об именовании. Как и в примере с папками на компьютере, будет лучше, если у нас будет заранее спланированная структура, с единым подходом в организации файлов.
Мы рекомендуем проработать соглашение об именовании папок, прежде чем начать разработку.
Давайте рассмотрим каждый пример и объясним, какой из них в каких случаях имеет смысл использовать.
Варианты организации папок
Одна папка
Один уровень вложенности, универсальное имя папки
Полезно при создании компонентов, которые не относятся к конкретной странице или контенту.
Когда мы видим универсальное имя папки, становится очевидным, что эта папка используется глобально по всему проекту.
Такое универсальное именование отлично подходит для повторяющихся основных элементов в проекте.
one-folder_name-of-element
Один уровень вложенности, специфическое имя папки
Полезно при создании любого типа пользовательских папок, независимо от размера проекта.
Используйте имя страницы, чтобы показать связь папки с конкретной страницей.
Добавьте ключевые слова, специфические для контента, чтобы предоставить больше информации о назначении класса.
Специфическое именование хорошо подходит для небольших сайтов, не требующих сложной глобальной структуры.
Специфическое именование идеально подходит для секций, компонентов и элементов, созданных для определенной страницы или элемента.
one-specific-folder_name-of-element
Один уровень вложенности, имя страницы в качестве имени папки
Полезно при создании папки классов, используемых только для определенной страницы.
Если мы создаем новую страницу, и эта страница имеет пользовательские компоненты, отличные от остальных на сайте, мы можем разместить эти компоненты внутри одной папки с именем страницы.
Папка с именем страницы - хорошая стратегия, когда на странице нет большого количества пользовательских классов, и эти пользовательские классы созданы для конкретной страницы.
page-folder_name-of-element
Важно: Не используйте на других страницах классы из папок, специфических для какой-либо конкретной страницы. Это приведет к неорганизованной и запутанной системе классов. Вместо этого, если мы используем класс на нескольких страницах, используйте стратегию " Один уровень вложенности, специфическое имя папки". При использовании имени страницы в наименовании папки мы должны использовать такой класс только на конкретной странице.
Один уровень вложенности, имя страницы в качестве префикса элемента
Полезно при создании уникальных вариаций компонента по странице, сохраняя при этом структуру папок компонента.
Например, каждый слайдер в проекте имеет одни и те же стили. На главной странице есть уникальная вариация стрелок вправо-влево. Этого недостаточно, чтобы назвать компонент уникальным слайдером или создать совершенно отдельную папку специально для этой вариации, ведь он стилизован также как остальные слайдеры, но с небольшими изменениями.
Мы хотим сохранить все компоненты слайдера внутри папки slider_.
Мы можем использовать префикс страницы в качестве первого ключевого слова идентификатора элемента, чтобы определить назначение нового класса в папке slider_.
Мы соотносим элемент с именем страницы, на которой он используется, не создавая новую папку для компонента слайдера.
one-folder_page-name-element
slider_culture-pane
Могли бы мы использовать для этого комбинированный класс? slider_pane is-culture
Да, вместо этой стратегии можно использовать комбинированный класс. Использование комбинированного класса также может быть правильным решением.
Однако могут быть причины, по которым мы не хотим использовать комбинированный класс для этой вариации. Например, нам не нужно наследовать стили из slider_pane. Более подробная информация об разумном использовании комбинированных классов в Стратегии классов 2.
Вложенные папки
Полезны на больших сайтах с более сложными требованиями к организации.
Использование вложенных папок не обязательно должно быть стратегией для всего сайта.
Мы можем использовать вложение папок только для некоторых папок или для одного конкретного случая.
Наличие возможности использовать вложенные папки не означает, что мы всегда должны их использовать. Используйте вложенные папки только тогда, когда есть конкретное преимущество.
Вложенные папки, папка с именем страницы на первом месте
Полезно для идентификации группы компонентов по имени страницы.
Если компоненты на каждой странице уникальны, и мы хотим находить их по имени страницы, эта стратегия может помочь нам.
Если мы понимаем, что использование название страниц – самый подходящий способ организации компонентов, то эта стратегия может помочь нам.
page-folder_keyword-folder_name-of-element
Вложенные папки, папка с ключевым словом на первом месте
Полезно для идентификации компонента по ключевому слову, а затем по названию страницы.
Если одна и та же категория компонентов имеет уникальные вариации на разных страницах, мы можем использовать ключевое слово как основу для организации структуры.
При переходе в папку компонента, мы можем увидеть все страницы, на которых есть уникальные экземпляры этого компонента.
keyword-folder_page-folder_name-of-element
Вложенные папки, любая варианты организации
Мы ценим гибкость.
Выше мы показали разные варианты работы с папками, но факт в том, что не каждое решение о наименовании очевидно. Иногда нам может идеально подойти одна из описанных выше стратегий. Иногда нам придется придумать какую-то иную стратегию, лучше подходящую к нашей задаче.
Мы можем использовать папки для всего. Нет строгих правил, когда мы говорим про соглашение об именовании пользовательских классов.
Можно использовать любую стратегию организации папок, если она удобна для вашего текущего проекта.
Имя страницы в имени класса
Решение добавить имя страницы в имя класса представляет собой мощный инструмент. Ниже мы рассмотрим вопросы, которые следует задать себе в каждом проекте.
Добавляя имя страницы в имя класса, мы делаем наши компоненты более понятными и контекстно связанными. Мы можем указать для себя или для следующего разработчика, что класс специфичен для данной страницы.
Также мы можем указать для себя или для следующего разработчика, что класс не специфичен для страницы, и его можно использовать глобально на любой странице, просто не указывая в имени класса имя страницы.
Гибкие варианты использования имени страницы
- Имя страницы может быть в имени папки.
- Имя страницы может быть в идентификаторе элемента.
- Ключевые слова могут использоваться вместе с именем страницы, как в имени папки, так и в идентификаторе.
С таким гибким подходом мы можем организовать наши проекты в соответствии с нашими задачами.
Помните, что добавление имени страницы - это наше решение. Нам требуется создать проект, с которым будет легко работать, и который будет удобно редактировать в Webflow для следующего пользователя. Если использование имени страницы поможет нам лучше понимать проект, тогда добавьте имя страницы.
Чтобы принимать более обоснованные решения об использовании имени страницы, мы можем задать себе следующие вопросы:
Стилизован ли этот элемент только для этой страницы?
Если класс создан для определенной страницы, лучше всего использовать имя этой страницы в имени класса.
У класса есть конкретная цель сделать [что-то] с элементом на этой конкретной странице.
Добавление имени страницы дает понимание цели этого класса.
Здесь мы показываем три примера имен страниц в имени класса. Каждый пример имеет два варианта именования - один уровень вложенности и два уровня вложенности папок.
page-component_element-name или page_component_element-name
- home-slider_arrow или home_slider_arrow
- team-slider_arrow или team_slider_arrow
- portfolio-slider_arrow или portfolio_slider_arrow
С именем страницы в имени класса мы можем предположить, что данный класс специфичен для этой страницы. Он не будет конфликтовать с другими страницами. Мы можем редактировать класс, зная, что мы редактируем только конкретный элемент на этой странице.
Является ли это повторно используемым элементом в проекте?
Если повторное использование компонентов и элементов в проекте необходимо для нашей работы, то, возможно, лучше всего не использовать имя страницы в таких именах классов.
В этом случае лучше использовать ключевое слово как имя папки базового уровня.
Мы не хотим определять наши компоненты как специфичные для страницы, если компонент не специфичен для страницы.
Если класс предназначен для использования в другом месте проекта, или есть вероятность его использования в другом месте проекта, то, возможно, не стоит использовать имя страницы.
Здесь мы показываем несколько примеров повторно используемых элементов, которые не специфичны для страницы. Их именование достаточно общее, чтобы ясно указать, что они повторно используемые.
specific-topic_element-name
slider_arrow
header_image-right
subscribe_form-input
clients-logos_row
Если имена классов заданы достаточно общее и не привязаны к конкретным страницам, новому разработчику, присоединившемуся к проекту, будет проще ориентироваться в проекте.
Класс slider_arrow не специфичен и, вероятно, может быть использован на всех или большинстве слайдеров. На панели Styles, мы можем видеть, что он используется 2 раза на этой странице и на 4 раза других страницах. У нас достаточно информации, чтобы предположить, что это повторно используемый элемент в нашем проекте.
Если бы мы создавали новую страницу в проекте, мы бы с уверенностью использовали этот класс без переименования. Мы бы также были спокойны, что не случайно не изменим другие элементы со стилями, уникальными для новой страницы.
Именование класса с общим ключевым словом дает понимание влияния этого класса на проект.
Когда использовать имя страницы (или специфическое ключевое слово) как префикс элемента?
Продолжим с примером в предыдущем разделе. У нас есть папка slider_, предназначенная для использования во всем проекте.
Представьте, что есть вариация слайдера на странице с отзывами. Слайдер на этой странице имеет другой визуальный образ стрелки. Это вариация, которая отличается от стандартного slider_arrow, в которой отличается всё.
Этот слайдер с отзывами наследует все основные стили компонента слайдера, за исключением стрелок. Поскольку это незначительная вариация, нет смысла переименовывать все как testimonials-slider_ компонент. Также мы хотим использовать стандартные стили слайдера, чтобы сохранить консистентность по всему проекту.
Вариация не настолько значительна, чтобы создавать уникальный компонент или новую папку. Нам нужны только другие стрелки для страницы с отзывами.
Мы можем использовать комбинированные классы или новый пользовательский класс с именем страницы в качестве префикса элемента.
Сначала мы покажем подход с использованием пользовательского класса.
Здесь показан компонент слайдера с двумя классами, специфичными для страницы отзывов. Мы не создаем уникальную папку. Мы дополнительно уточняем элемент внутри папки slider_.
Оба slider_testimonials-arrow и slider_testimonials-arrow-trigger используют слово "testimonials" как первое ключевое слово имени элемента.
Ключевое слово "testimonials" говорит нам, что элемент слайдера специфичен для элемента с отзывами.
Не всегда понятно, используем мы имя страницы или ключевое слово
Имена страниц могут быть ошибочно приняты за имена ключевых слов - или имена ключевых слов могут быть ошибочно приняты за имена страниц.
Мы не всегда уверены на 100%, видим ли мы в наименовании класса имя страницы или ключевое слово. Однако соблюдение принципов именования помогают нам поддерживать порядок.
Например, testimonials_slider использует "отзывы" в качестве ключевого слова или имени страницы.
У нас может быть страница клиента со слайдером отзывов.
У нас может быть страница с отзывами со слайдером.
Этот класс может существовать на многих страницах и использоваться для слайдеров, содержащих множество типов отзывов.
Мы, как разработчики проекта, можем знать, что означает testimonials_. Однако другие, работающие с сайтом после нас, могут не знать этого.
Нет волшебного решения для идентификации ключевых слов и их значений для каждого класса. Затруднительно сделать каждый класс нашего проекта на 100% понятным, независимо от используемой нами системы именования.
Однако, мы стремимся к максимальной ясности. Именно поэтому мы применяем систему "Client-First".
Иногда возникают конфликты имен, и это нормально.
При использовании имен максимально отражающих суть и назначение класса, мы соблюдаем принципы "Client-First" и обеспечиваем высокий уровень организации в нашем проекте.
Одна папка или две папки
Мы должны разумно использовать папки согласно принципам "Client-First".
Только потому, что мы можем вкладывать папки друг в друга, не означает, что мы всегда должны это делать. Размер нашего проекта и уровень организации, который требуется, должны быть двумя основными факторами при принятии решения о глубине вложенности папок.
Если в нашей папке testimonials_ есть 100 различных вариантов элементов, может быть логично использовать вложенную папку для дальнейшей организации этих классов. Может быть полезно иметь дополнительный "уровень" организации для этих 100 различных элементов.
Если в нашей папке clients_ есть 12 элементов, то, вероятно, нецелесообразно использовать вложенные папки. Нужно ли нам дополнительно заниматься размещением этих 12 элементов? Возможно, но скорее всего, нет.
Решение о том, использовать один или два уровня папок для нашего проекта, полностью зависит от нас.
Для одной части проекта мы можем использовать один уровень папок, а для другой можно использовать два уровня. Мы можем настроить количество папок так, как нам удобно.
Пример с использованием аналогии компьютера
Давайте рассмотрим пример с использованием аналогии компьютерной папки.
Пример: У нас есть excel-файл со всеми нашими университетскими оценками. Нам нужно поместить этот файл на наш компьютер.
> У нас есть папки папки уровня "Личное", "Школа", "Сторонний проект", и "Работа".
>> В папке "Школа" у нас есть "Магистратура", "Начальная школа", "Университет".
>>> В папке "Университет" мы видим наш файл "university-test-scores.xls".
Это структура папок, которая подходит для многих личных компьютеров. Мы используем разные папки для различных ситуаций или разных периодов нашей жизни.
В нашей папке "Школа" есть сотни файлов в каждой из папок "Начальная школа", "Университет" и "Магистратура".
Было бы неудобно использовать файлы, помещенные в одну папку под названием "Школа".
Если мы бы захотели найти файлы, относящиеся к "Университету", это было бы сложно, так как файлы, относящиеся ко всем трем уровням образования, находились бы в одной папке.
Найти один файл среди сотен файлов было бы сложно. Создание второго уровня папок позволяет размещать файлы более структурировано, что делает работу с ними удобнее.
Теперь представьте личный компьютер маленького ученика начальной школы. У него нет работы или сторонних проектов. У него есть только "Школа" и "Личное".
На компьютере ученика начальной школы меньше файлов, чем у студента-магистра, который пользуется своим компьютером с начальной школы.
Для нашего юного ученика:
> У нас есть папки базового уровня "Школа" и "Личное"
>> В папке "Школа" находится 12 файлов. У этого ученика не так много школьных файлов. Мы легко можем найти наш файл "geography-test-scores.xls" среди этих 12 файлов.
Если бы мы создали для этих 12 файлов структуру папок такую же, как у студента-магистра, поиск файла мог бы стать более сложным.
Больше кликов и больше размышлений о том, где искать нужный файл. Если нам не нужна вложенная папка для оптимизации работы, мы не должны ее создавать.
Вложенные папки должны помочь нам работать быстрее, а не медленнее.
Библиотеки компонентов
Библиотеки компонентов, такие как библиотека Relume, выигрывают от использования вложенных папок. Или даже от большого количества вложенных папок.
Папки улучшают организацию библиотек компонентов любого размера. Покажем это на примере использования библиотеки компонентов.
В библиотеке компонентов мы можем захотеть организовать классы следующим образом:
-
slider1_component
-
slider2_component
-
slider3_component
-
grid1_component
-
grid7_component
-
logo-row1_component
-
logo-row2_component
Нет правильного способа назвать компоненты в библиотеке компонентов, чтобы они были специфичны для каждого элемента.
Цель библиотеки компонентов - создать повторно используемые компоненты, которые можно использовать в любом месте нашего проекта.
Если в библиотеке компонентов находится 100 компонентов, мы увидим 100 папок в нашей виртуальной системе папок. Этот список может быть не очень удобным для навигации.
Добавление одного символа подчеркивания может помочь нам лучше организовать наши компоненты для обозначения вариаций и опций.
Те же классы были переписаны, чтобы включить вложенную папку с номером вариации.
-
slider_1_component
-
slider_2_component
-
slider_3_component
-
grid_1_component
-
grid_7_component
-
logo-row_1_component
-
logo-row_2_component
Посмотрите, какой красивый результат дает использование такого соглашения об именовании.
Мы можем организовать все типы наших компонентов как папки базового уровня. Когда мы переходим в каждую папку, мы видим, сколько вариантов доступно. Каждая вариация ясно определена и организована в своей папке.
Для очень больших библиотек компонентов с множеством вариаций может быть разумным использовать три уровня папок - вложенные папки во вложенные папки.
Мощное переименование с помощью расширения Finsweet
Сразу после того, как компонент появится в нашем основном проекте, мы сможем переименовать всю папку с помощью расширения Finsweet.
Используя расширение Finsweet, можно переименовать сразу все классы, помещенные в какой-либо папке.
Это означает, что мы можем скопировать layouts_grid_1_ в наш проект и одним действием переименовать каждый элемент в этой папке в team-grid_. Это массовое переименование папок занимает секунды, благодаря использованию расширения.
Более подробная информация о возможностях расширения Finsweet на странице Папки.
Использование ключевого слова _component
В первой версии Client-First V1 компоненты определялись так:
Компоненты в Client-First - это группа элементов страницы, которые создают полный UI элемент. Например, форма подписки на новости, блок фотографий команды, калькулятор цен, повторно используемая сетка из 3 столбцов или блок со списком клиентов.
Компоненты в Client-First всегда определялись как использование символа подчеркивания в имени класса.
Все это по-прежнему актуально. В этом обновлении папок мы будем более конкретны, когда используем компоненты — и более точны при использовании символов подчеркивания!
V1 Первая версия
символ подчеркивания в имени класса = компонент
V2 Версия с Папками
символ подчеркивания в имени класса = папка
[folder-name]_component = component
Использование символа подчеркивания в имени класса для обозначения папки не обязательно означает, что папка является компонентом. Теперь мы используем символы подчеркивания для организации или группировки элементов в Папках.
У компонентов теперь есть специфическая классификация. Если мы хотим, чтобы элемент был компонентом, мы используем слово "component" для идентификации элемента.
Использование ключевого слова "component" говорит нам, что эта папка представляет собой компонент — группу элементов страницы, которые создают полный UI элемент.
Мы представить о компонент как полную структуру, которую можно копировать. Мы копируем всю структуру из класса _component.
Например, у нас может быть слайдер клиентов на веб-сайте. Мы считаем этот слайдер клиентов компонентом. Тогда для родительского элемента, содержащего все элементы слайдера клиентов, надо добавить ключевое слово component.
- client-slider_component
- client-slider_mask
- client-slider_grid
- client-slider_arrow
Это говорит нам, что папка clients-slider_ является компонентом.
Такие структуры, как форма подписки на новости, блок о команде, калькулятор цен или список клиентов, являются отличными примерами компонентов. Однако, не всё должно быть компонентами.
Иногда мы захотим использовать папки для группировки без использования компонентов.
Например, папка руководства по стилю. Если наш проект Webflow использует руководство по стилю, нам, вероятно, потребуется создать классы для руководства по стилю. Классы руководства по стилю могут быть на одной странице. Классы могут использоваться на нескольких страницах.
Для организации классов руководства по стилю, мы можем поместить их в специально созданную папку.
- styleguide_structure
- styleguide_content
- styleguide_item
- styleguide_sidebar
Наша страница руководства по стилю не является компонентом. Это просто организация элементов.
Добавление ключевого слова _component не является обязательным. Как разработчики, мы сами решаем, добавлять ли 'тег' компонента как идентификатор элемента в имени класса.
Дерево принятия решений при использовании папок
Есть много решений, которые нужно принимать, когда мы организуем наш проект.
Некоторые решения стоит принять до того, как мы начнем разработку.
Многие решения будут приниматься в процессе разработки.
Возможно, когда мы впервые начнем принимать решения о наименовании папок, это будет занимать много времени. Принятие быстрых и грамотных решений по наименованию приходит с практикой.
Принятие решений о наименовании папок - это то, что мы улучшим, продолжая использовать Client-First.
Наша скорость и точность улучшатся по мере того, как мы продолжим использовать функционал Папок в наших проектах.
Мы разработали дерево принятия решений, чтобы помочь разобраться, как принимать быстрые решения об организации классов.
Просмотрите PDF-файл Решений о папках.
Возможно, вам потребуется некоторое время, чтобы ознакомиться с этим файлом. Однако нам не понадобится много времени, чтобы принимать решения по каждому наименованию. По мере того, как мы продолжим применять эту логику к нашим решениям об именовании классов, решения станут приниматься быстрее.
Мы сможем быстрее принимать сложные решения благодаря практике, экспериментам и опыту.
Есть вопрос, на который вы не нашли ответ в документации? Спросите нас в X (Twitter).