Як зібрати гнучку систему таблиць у Figma з двох компонентів

Архівний матеріал: розбір публікації від 2022-06-17. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.

У матеріалі розбирається підхід Андрія Ждана до побудови й підтримки таблиць у Figma. Він показує, як почати з двох базових компонентів і поступово перетворити їх на гнучкий набір для реальних продуктів з різними станами й розмірами.

1. Базові осередки й каркас таблиці

Автор у своїх проєктах часто спирається на компоненти таблиць з Ant Design, але саме у Figma все зводить до мінімуму. Стартова задача проста: зробити тільки два компоненти й на їх основі зібрати будь яку таблицю.

head cell — осередок заголовка;
row cell — осередок рядка.

У текстових шарах цих компонентів застосовуються налаштування Constraints з горизонтальним вирівнюванням Left або Center — це дозволяє контролювати поведінку тексту при зміні ширини.

Create two components: a head cell, and a row cell.

Щоб швидко нарощувати сітку, автор використовує комбінації клавіш:

Alt/Option + Shift + drag — копіювання шару або компонента по прямій;
Ctrl/Cmd + D — повтор останньої дії (наприклад, копіювання з тим самим зсувом).

Після розкладки кількох head cell і row cell у ряд, елементи об'єднуються в компоненти «table head» і «table row» через Alt/Option + Ctrl/Cmd + K. Важливий організаційний момент автора — давати імена компонентам на кожному рівні, щоб не розгрібати хаос пізніше.

Naming the components.

Фрейм, який дає рамку, фон і міжрядкові лінії

Щоб отримати акуратну таблицю з рамкою, кутовим радіусом і лініями між рядками, автор групує рядки в один фрейм і стилізує вже його, а не кожен рядок окремо. Приклад технічних вимог:

між рядками 1 px синіх горизонтальних ліній;
зелена рамка по периметру таблиці;
радіус кутів таблиці 15 px.

Styling the table border, the row lines, and the table corner radius.

Кроки, які пропонує автор:

об'єднати всі рядки таблиці в один Frame;
задати corner radius 15 px на цьому фреймі;
встановити stroke 1 px з кольором #49E36B для зовнішньої рамки;
вибрати fill фрейма, наприклад #278EEE, щоб сформувати колір горизонтальних ліній.

Group the table row elements into a single frame and adjust the parameters.

Автор окремо показує схему, де різними кольорами виділені:

рядки;
фрейм, що задає фон і рамку;
обтинання контенту фреймом з радіусами.

The table elements.

Увімкнений параметр на кшталт «crop frame content» дозволяє обрізати вміст по радіусу. Якщо додати до цього Auto layout для вертикального розміщення рядків, можна додавати нові рядки через Ctrl/Cmd + C, Ctrl/Cmd + V або видаляти їх — структура автоматично перебудується.

2. Підстановка реальних даних і корекція ширини колонок

Коли кістяк таблиці готовий, автор переходить до заповнення її реалістичним текстом. Для масового наповнення текстових шарів у фреймі він виділяє їх із затиснутою клавішею Ctrl/Cmd і підключає плагін Content reel.

Після цього в роботу вступає Auto layout для рядка. Схема така:

сам рядок як Frame у горизонтальному авто лейауті має режим ширини Fixed — розмір контролюється вручну;
кожна клітинка всередині рядка може бути або Fixed, або Fill по горизонталі, залежно від того, чи має вона тягнутися.

Frame → Horizontal → Fixed (for the row).

Frame → Horizontal → Fill (for the cell).

У результаті виникає поведінка, зручна для зміни колонок:

щоб змінити ширину — автор радить затиснути Shift, двічі клікнути по колонці, а потім тягнути її край;
щоб змінити порядок колонок — просто перетягнути відповідний компонент усередині авто лейауту рядка.

3. Робимо таблицю адаптивною

Далі автор переходить до сценарію з фіксованими й адаптивними колонками. Базовий приклад:

head cell (140) — фіксована ширина 140 px;
row cell (140) — фіксована ширина 140 px;
head cell (~) — адаптивна по ширині колонка;
row cell (~) — адаптивна по ширині колонка.

Рядок з кількох осередків знову зібраний у горизонтальний авто лейаут з режимом Fixed для самого фрейма рядка.

Frame → Horizontal → Fixed (for the rows).

Далі:

для клітинок, які мають залишатися фіксованими, застосовується горизонтальний розмір Fixed;

Frame → Horizontal → Fixed (for the fixed-size cells).

для клітинок, які повинні розтягуватися й забирати вільний простір, використовується режим Fill.

Frame → Horizontal → Fill (for the responsive cells).

Щоб таблиця реагувала на зміну ширини вищого контейнера, саму таблицю перетворюють на Frame, а для кожного рядка всередині цього фрейму в Constraints встановлюють горизонтальний режим Left and right. Це дозволяє рядкам тягнутися разом з шириною батьківського фрейма.

Constrains → Horizontal → Left and right (for all rows in the table).

У підсумку ширина таблиці змінюється, фіксовані колонки зберігають свої значення, а адаптивні клітинки підлаштовуються, ділячи залишок простору.

4. Базовий table kit і стани осередків

Для реального проєкту автору недостатньо лише двох типів клітинок. Він пропонує зібрати базовий набір станів і замкнути їх на вихідні компоненти через variants.

Building a basic table kit.

Умовна структура набору:

набір іконок, які використовуються саме в таблицях;
базові стани заголовків колонок (звичайний, hover, сортований, disabled тощо — конкретні варіанти проєкт залежить від продукту);
базові стани клітинок (звичайна, вибрана, помилка, success, з іконками, з чекбоксом тощо).

Окремий бібліотечний набір саме «table icons» допомагає уникати ситуації, коли різні дизайнери підтягують несумісні значки для однакових дій.

Типові комбінації в клітинці

Автор виділяє кілька базових комбінацій контенту:

лише текст;
лише іконка або група іконок;
змішані варіанти: текст + іконка, текст + чекбокс, текст + action кнопки, селекти, тумблери тощо в різному порядку.

Важлива порада з боку автора — не ховати критичний контент у hidden layers. Під час побудови дизайн системи про ці шари ще пам'ятають, але ті, хто будуть користуватися компонентами пізніше, можуть їх навіть не помітити.

Пара прикладів поведінки компонентів

У першому прикладі автор показує клітинку з простими constraints для вмісту.

Set the following constraints options.

У другому прикладі використано Auto layout усередині клітинки, де:

текст може розширювати фрейм по ширині;
іконка завжди залишається праворуч, незалежно від довжини тексту.

The text can change the Frame size, and the icon should always be on the right side.

Коли такі типи клітинок підготовлені, їх можна поступово підміняти у вже зібраній раніше таблиці, яка спочатку складалася лише з двох простих компонентів. Це дозволяє почати з «wireframe» варіанту й згодом «оживити» її додатковими станами без повної перебудови.

The basic table kit that we made in Figma.

Автор також звертає увагу на можливість використати Figma Properties, щоб зробити компоненти компактнішими замість вибуху варіантів. Детальні інструкції він пропонує шукати у відео Figma «Jumping into component properties» з події Figma Config 2022.

Example of the structure using ‘Figma Properties’.

5. Файл прикладу й додаткові ресурси

Для розбору на практиці автор підготував файл Figma Design file, де зібрана демонстраційна таблиця саме за описаним підходом. У ньому можна переглянути налаштування авто лейауту, constraints і структуру компонентів.

The table that I have created (Figma Design file) for the purposes of this tutorial.

Наприкінці автор ділиться ще кількома матеріалами про таблиці у Figma:

Creating Tables In Figma Саші Бєліченко — приклад побудови таблиці через компоненти та Atomic Design;
Create a Figma Prototype with Data from Google Sheets Браяна Елкуса — детальний огляд плагіна Google Sheets Sync для підвантаження даних з Google Sheets у макети;
Creating Tables in Figma with Auto Layout Гевіна МакФарланда — файл прикладу з повністю «fluid» таблицями на Auto layout.

6. Практичні рекомендації автора з підтримки таблиць

У завершальній частині Андрій Ждан ділиться практичними висновками з власних проєктів. Це не універсальні правила, а саме спостереження з його досвіду:

Лінії з боку дизайн системи. Якщо лінії (бордери) винесені в компоненти дизайн системи, можна оновити всі таблиці з одного місця. Але будь яка зміна потребуватиме публікації оновлень на рівні дизайн системи.
Окремі файли завдань. Якщо задачі ведуться в окремих Figma документах, автор радить від'єднувати такі файли від бібліотеки дизайн системи, щоб уникнути неконтрольованих оновлень.
Обмеження ресайзабельних компонентів. На перший погляд зручно мати один компонент, що масштабується. Але коли з'являються різні стилі для різних висот рядків, підтримка такого підходу стає складною. Для таблиць з різною висотою рядків автор рекомендує окремі компоненти для кожного варіанта.
Не гнатися за мінімумом компонентів. Є підхід «якнайменше компонентів», але в реальній роботі частіше працюють із variants, а не з окремими майстер компонентами. На думку автора, краще мати достатньо дрібних компонентів і варіантів, ніж покладатися на приховані шари й вкладені структури, якими важко керувати.
Дві лінії тексту як базовий сценарій. Кожна клітинка таблиці має без конфліктів підтримувати щонайменше дві лінії тексту. Автор згадує налаштування line spacing 16 px як один із способів цього досягти.
Мінімальна ширина колонок. Він радить визначати мінімальну ширину для батьківських компонентів колонок. Ці значення бажано узгодити з front end розробниками, щоб таблиці у верстці могли повторити поведінку з дизайну.
Окрема колірна палітра для таблиць. Навіть якщо в системі вже є загальна палітра, автор пропонує виділити окремий набір кольорів саме для таблиць. Інакше при спробі змінити, наприклад, колір тексту або фон рядка можна зіткнутися з небажаними ефектами в інших частинах продукту.
Окремі текстові стилі для таблиць. У таблицях зазвичай інші вимоги до меж рядків, розміру й інтерліньяжу, ніж у стрічках новин чи статтях. Виділення власних текстових стилів для таблиць спрощує подальшу підтримку.

Автор підкреслює, що описаний набір — лише один із можливих способів структурування таблиць у Figma. У власних проєктах він використовує складніші кіт-набори, але для практичного старту достатньо саме двох базових компонентів, авто лейауту й поетапного додавання станів.

Джерело: Andrii Zhdan – Smashing Magazine. Дата оригіналу: 2022-06-17.