Вскрытие магии или дизайн масштабируемых проектов (Часть1)


Сейчас, наверное, все остро прочувствовали необходимость в систематизации интерфейсныйх процессов, кто-то поддался заразительному примеру, кто-то в погоне за экспериментами, а в нашем случае это был неизбежный эволюционный процесс. Наш дизайнерско-разработческий синдикат принял эту инициативу, но все было довольно размазано. Мы не нашли ни одного достойного примера такой реализации. Поэтому просто отталкивались от задач.

Технологии

Методология верстки

На тот момент наша команда верстальщиков была еще совсем не большой. Но у каждого были свои особенности/стиль верстки и разные инструменты. Это усугублялось грузом в виде старых поддерживаемых проектов. Учитывая небольшую и готовую к переменам команду, мы начали процесс притирки. Не буду углубляться в детали. Хоть на то время нам явно не хватало верстальщеских мощностей, но тот количественный и личный состав был именно тем, что надо. Так у всех был опыт, доля экспертности в смежных областях и нужный азарт.

В итоге была выбрана методология многослойного CSS, основанная на БЭМ. Не обошлось конечно без пары напряженных код ревью, но в целом синхронизация произошла на том уровне, чтоб можно было не бояться масштабироваться. На самом деле, этот процесс не останавливается и сейчас, с учетом добавления новых участников в команду и внедрение технологий. Но это уже логичное развитие.

Препроцессор Sass + Bourbon

Пробовали все, но остановились на Sass. Различия между всеми были не настолько критичны для нас и по сути на том этапе мы могли взять любой. Но Less уже умирал, Stylus только оживал, а Sass был проверенным и дико популярным (Я очень падок на популярность, за что меня чаcто “ругает” команда). Про PostCSS тогда еще не слышали, но сейчас его уже трудно игнорировать. В качестве библиотеки примесей взяли Bourbon.io вместо Compass (нам он пришелся больше по душе)

Документация

Документация. Её роль трудно переоценить. Особенно когда идет становление процесса. Честно признаться, нам сильно повезло и мы долго не парились по этому поводу. Не потому что мы халатно к этому отнеслись, а просто альтернатив практически не было. Насколько я знаю, их и сейчас нет. А SourceJS идеально вписывался под наши требования. Нам достаточно было увидеть небольшую демку еще тестовой версии, чтоб убедиться в её крутости. Конечно настройка ее заняла достаточное количество разработческих ресурсов.

Гайды и элементы

Следующий этап синхронизации был более сложен. Так как он вовлекал дизайнеров. Но инициативность была ответной. Я помню, как получил графический файлик от дизайнера с несколькими кнопками и контролами. Я непременно заверстал это, добавив еще элементов и типографику. Дальнейшее развитие этого уже было вопросом времени.

Структуры еще не было но нужно было обозначить кирпичики.

Гайды и элементы

Мы разбили весь интерфейс на мелкие оставляющие:

1. Цвета (базовые + цвета проектов в связке с Sass переменными. Тем самым мы имеем достаточно небольшое и самое нужное количество цветов, а все остальное это производные от них через Sass. И для новых проектов нам достаточно указать основную переменную цвета, а все производные от нее генерируется автоматически)

2. Типографика (спасибо Горбунову, мы тщательно изучали его статьи)

3. Инпуты и текстовые поля

4. Чекбоксы и радио (знаю что есть много споров на этот счет, но но мы не смогли перешагнуть через элементарную эстетику, поэтому все мы их все таки стилизовали)

5. Селекты (ситуация аналогичная)

6. Списки

Sass colors

Косметики

Это те свойства, которые мы можем применять в любых компонентах и элементах на любом проекте.

1. Внутренние и внешние отступы с шагом.

2. Display (block, inline-block, inline)

3. Отступы внутренние и внешние (с шагом)

Архитектура

На первый взгляд все довольно просто понятно и логично. Есть проект, внутри папка компонента, в которой лежит разметка, стили, js и изображения, но был один нюанс в том, что проектов у нас не один и не два, как минимум старт начался с 4 одновременно. В них было много общего, но также было много различий, мы хотели максимально избежать дублирования кода. Сделать какую-то общую эко-систему, но всё же иметь возможность безболезненной модифицировать каждый проект по отдельности. После пары недель обдумывания, выкристолизовалась явная структура всей системы. Несомненное в течении нескольких месяцев после этого мы не раз все допиливали, пробегаясь по проектам. Мы сделали общий кит (для всех проектов), составляющие которого потом импортировались из проектов и уже там переопределялись.

Общий кит

kit/
├── base
│ ├── fonts
│ ├── index.html
│ ├── stylesheets
│ │ ├── lib
│ │ │ ├── bourbon
│ │ │ └── custom
│ │ │ ├── lib-1
│ │ │ ├── ...
│ │ │ └── lib-4
│ │ ├── sass
│ │ │ ├── _base.sass
│ │ │ ├── base_.sass
│ │ │ ├── _cosmetic.sass
│ │ │ ├── cosmetic_.sass
│ │ │ ├── _variables.sass
│ │ │ ├── _mixins.sass
│ │ │ └── _icons.sass
│ │ └── css
│ │ ├── base.css
│ │ └── cosmetic.css
│ └── js
│ ├── lib
│ │ ├── lib-1
│ │ ├── ...
│ │ └── lib-4
│ └── custom
│ ├── lib-1
│ └── lib-2
└── components
├── index.html
└── stylesheets
├── sass
│ ├── _components.sass
│ └── components_.sass
└── css
└── components.css

Кит проекта

Сюда импортируются составляющие кита и переопределяется здесь, в зависимости от требований проекта.

project/
├── base/
│ ├── index.html
│ ├── stylesheets/
│ │ ├── sass/
│ │ │ ├── base.sass
│ │ │ ├── _variables.sass
│ │ │ ├── _mixins.sass
│ │ │ └── _icons.sass
│ │ └── css/
│ │ └── base.css
│ └── js/
│ └── main.js
└── components/
└── stylesheets/
├── sass/
│ └── components.sass
└── css/
└── components.css

Директории компонентов

Тут все просто, это изолированный самодостаточный кусок, который может реиспользоваться и модифицироваться.

project-1/
└──component-1/
├── index.html
├── stylesheets/
│ ├── sass/
│ │ └── component-1.sass
│ └── css/
│ └── component-1.css
└── js/
└── component-1.js
Компонент плитки продукта. Скриншот из SourceJS

Вся экосистема

Структурно вся эко-система выглядит примерно так.


eco-system/
├── kit/
│ ├── base/
│ │ ├── fonts/
│ │ ├── index.html
│ │ ├── stylesheets/
│ │ │ ├── lib/
│ │ │ │ ├── bourbon/
│ │ │ │ └── custom/
│ │ │ │ ├── lib-1
│ │ │ │ └── lib-2
│ │ │ ├── sass/
│ │ │ │ ├── _base.sass
│ │ │ │ ├── base_.sass
│ │ │ │ ├── _cosmetic.sass
│ │ │ │ ├── cosmetic_.sass
│ │ │ │ ├── _variables.sass
│ │ │ │ ├── _mixins.sass
│ │ │ │ └── _icons.sass
│ │ │ └── css/
│ │ │ ├── base.css
│ │ │ └── cosmetic.css
│ │ └── js
│ └── components/
├── project-1/
│ ├── base/
│ │ ├── index.html/
│ │ ├── stylesheets/
│ │ │ ├── sass/
│ │ │ │ ├── base.sass
│ │ │ │ ├── _variables.sass
│ │ │ │ ├── _mixins.sass
│ │ │ │ └── _icons.sass
│ │ │ └── css
│ │ │ └── base.css
│ │ └── js/
│ │ └── main.js
│ ├── components/
│ │ └── stylesheets
│ │ ├── sass/
│ │ │ └── components.sass
│ │ └── css/
│ │ └── components.css
│ ├── component-1/
│ │ ├── index.html
│ │ ├── stylesheets/
│ │ │ ├── sass/
│ │ │ │ └── component-1.sass
│ │ │ └── css/
│ │ │ └── component-1.css
│ │ └── js/
│ │ └── component-1.js
│ ├── ...
│ └── component-24/
├── ...
└── project-8/

Интеграция

Для начала нужно просто разметить основной каркас, а затем наслаждаться процессом интегрирую компоненты в сетку.

Grid + Component

Что дальше?

Дальше будет все более плотная интеграция с front-end процессом и повышение доступности/скорости для UX набросков. Это поможет стереть жесткие грани и заняться инженерией.

Кину для затравки несколько “инструментов”, которые нас уже ждут:

#BEMJSON #BEMCOMPONENTS #Protein.io #FramerJS

Like what you read? Give Mikhail Koloskov a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.