Кейс: Як я перетворив 30 варіантів компоненту налаштувань в 1 варіант і зробив його ще гнучкішим

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Контекст і хід робіт

На етапі вайрфреймів ми повністю затвердили логіку з клієнтом і базовий стиль.

Після цього я почав налаштовувати дизайн-систему та паралельно збирав hi-fidelity екрани

Коли дійшов до меню налаштувань, реалізував його як окремий компонент з 10 варіантами під різні сторінки

На етапі адаптації з’явилось ще 10 варіантів для мобайлу.

І тут стало очевидно що планшет ще +10, а підтримка і правки перетворяться на повний треш.

Проблема

Поточна реалізація не масштабувалась і створювала технічний борг.

Основні болі:

• 3 девайси (Desktop / Tablet / Mobile) в одному компоненті без чіткої структури
• Дублювання елементів, які доводилось правити вручну
• Відсутність стратегії наповнення контентом усередині компоненту
• Кожна нова правка = потрійна робота

Що потрібно було

Компонент має бути:

• єдиним
• гнучким
• контент-незалежним
• Адаптив і наповнення мають керуватись системно, а не через копіювання.

Рішення і підхід

Я повністю переосмислив логіку компоненту.

1. Компонент зі slot-підходом
   • Основний компонент меню має slot
   • У slot підставляються готові компоненти секцій
2. Контент винесений окремо
   • Кожна сторінка налаштувань = окремий компонент наповнення
   • Його можна незалежно редагувати і перевикористовувати
   • Також кожну таку сторінку можна адаптувати окремо.
3. Адаптив через токени
   • Desktop / Tablet / Mobile керуються токенами
   • Компонент автоматично адаптується без дублювання
4. Допоміжний навігаційний компонент
   • Створив компонент-обгортку на базі основного
   • В ньому зібрані всі сторінки одразу для швидкого перемикання і тестування

А тепер давайте детальніше по кожному моменту

Почав я з брейншторму в режимі максималізму.

Мета була одна — спроєктувати компонент так, щоб він покривав майже всі можливі сценарії, а не лише поточні екрани.

Заздалегідь заклав такі вимоги:

• Гнучке наповнення контенту без дублікатів
• Адаптація всього компоненту і його вмісту без створення окремих варіантів або з мінімальною їх кількістю
• Підтримка вспливаючих вікон підтвердження
• Різна навігація для різних девайсів

Першим і основним кроком стало розділення компоненту на слоти (Доречі тут використані не нативні слоти від фігма, а зроблені власноруч).

Slot-підхід дав:

• повний контроль над структурою сторінок
• можливість розглядати кожну сторінку як окремий незалежний компонент
• заміну контенту без впливу на базову логіку меню

Кожна сторінка налаштувань існує окремо і підставляється в слот, а не живе всередині головного компоненту.

Адаптив через токени і структурні компоненти

Наступним кроком я вирішив не робити адаптив через варіанти. Замість цього адаптація була закладена на рівні системи.

Основою стали: дизайн-токени та структурні компоненти, які керують головним компонентом.

Як це працює

Ключові параметри компоненту — відступи, розміри, поведінка навігації — винесені в токени.

При зміні брейкпоінту підтягується відповідний набір токенів та Структурні компоненти змінюють вид без дублювання логіки і контенту

Що це вирішило

• Один і той самий компонент працює для Desktop, Tablet і Mobile
• Адаптив перемикається автоматично
• Відпала потреба створювати окремі варіанти під кожен девайс
• Контент залишається незмінним і не ламається при адаптації

Заміна слотів і навігаційний компонент

Після цього робота з компонентом стала максимально простою.

У slot підставляється готовий компонент конкретної сторінки а Базовий компонент меню при цьому не змінюється взагалі

Таким чином сторінка існує окремо, але повністю підкоряється спільній логіці і адаптиву.

Навігаційний компонент для зручності

Щоб не перемикати сторінки вручну, я створив додатковий навігаційний компонент поверх основного.

Він містить усі сторінки налаштувань одразу, дозволяє швидко перемикатися між ними та не потребує перевідмальовування або дублювання компонентів

Що це дало

• Швидкий перегляд і тестування всіх сценаріїв
• Мінімум ручних дій
• Збереження єдиної структури і логіки
• Комфортну роботу з компонентом навіть при великій кількості сторінок

Документація для дизайнерів і розробників

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

Документація покриває:

• структуру компоненту і логіку слотів
• правила підключення готових сторінок
• поведінку адаптиву через токени
• сценарії навігації і використання
• обмеження і принципи масштабування

Цінність документації

• Дизайнери швидко розуміють, як додавати нові сторінки без дублікатів
• Розробники отримують прозору і передбачувану структуру
• Зменшується кількість питань і помилок
• Рішення живе довше за конкретний проєкт або команду

Загальний результат

Цей підхід дав відчутний системний ефект:

• 1 універсальний компонент замість 30+
• Повністю прибрані дублікати
• Автоматичне перемикання адаптиву
• Швидке редагування без ризику щось зламати
• Робота з компонентом стала у ~4 рази простішою
• Компонент легко масштабується під нові сторінки і девайси