Click to order

Практика 8

Организовать библиотеку компонентов

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

Тем не менее, правильная и понятная структура этого документа позволяет разработчикам сэкономить время, не перелопачивая все макеты в поисках неактивного состояния того или иного элемента или состояния «по ховеру».

Предыдущая практика

«Собака Павлова» в соцсетях

Как мы работаем с компонентами

1. Если заказчик не приходит к нам со своей дизайн-системой или запросом под фреймворк, мы используем нашу внутреннюю библиотеку компонентов, адаптируя и пополняя ее в ходе работы над проектом.

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

3. Все мастер-компоненты храним на отдельной странице или, при необходимости, в отдельном файле, что позволяет разработчику видеть все состояния элементов и стили структурированно.

4. Компоненты, относящиеся к тому или иному смысловому блоку интерфейса (например, все компоненты раздела «Авторизация», «Личный кабинет» и т. п.), объединяем в секции и называем соответствующим образом.

5. При необходимости в секциях также используем иерархию, отделяя разные смысловые блоки заголовками.

6. Если в процессе проектирования выясняется, что компонент нужно пересобрать со всеми его состояниями, — делаем это. Чем проще и логичнее компонент — тем проще разработчику разобраться в его состояниях и понять, как его правильно верстать.

7. Чтобы не рушились связи стилей-компонентов при передаче файла с локальными стилями и компонентами, необходимо создавать копию, удаляя ненужное. Если подключена внешняя библиотека, нужно убедиться, что она доступна для разработчиков.

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