Архівний матеріал: розбір публікації від 2019-09-25. Назви функцій, інтерфейс, можливості плагінів і умови доступу наведені в контексті того часу.
У статті розбирається підхід Саші Бєліченко до побудови таблиць у Figma за Atomic Design. Авторка пропонує дивитися на таблицю як на «організм», клітинку як «молекулу», а фон, рамку і контент — як «атоми», і будувати все строго через компоненти.
1. З чого складається клітинка таблиці
Клітинка розглядається як окремий компонент, який об'єднує три «атоми»:
- фон (background)
- рамку (border)
- контент (content)
Такий поділ дає два ключові ефекти:
- швидкі глобальні зміни стилів: змінюється майстер компонента, а не окремі клітинки
- масштабування: одна й та сама система клітинок використовується в різних таблицях і файлах через бібліотеку компонентів
2. Компонент фону: простий атом, який вирішує багато проблем
Авторка радить створювати фон як окремий компонент, навіть якщо він виглядає «примітивно».
Як зібрати компонент фону
- Створити компонент потрібного базового розміру, наприклад 100×36 px (конкретний розмір не критичний — він буде тягнутися).
- Всередину додати прямокутник такого самого розміру.
- Встановити йому constraints: «Left & Right» і «Top & Bottom», щоб він автоматично підлаштовувався під розмір компонента.
- Задати колір заливки з існуючого Color Style (у прикладі використовується білий).
Ключова ідея — фон відривається від контенту і рамки. Якщо пізніше потрібні, наприклад, смугасті рядки, альтернативний фон для header або стан hover, достатньо додати варіанти фонового компонента або окремі майстри для цих станів.
3. Компонент рамки: чому одна фігура зі stroke — погана ідея
Для коректної роботи з рамками однієї фігури з обвідкою не вистачає. Таблиці часто вимагають різних варіантів:
- повна рамка навколо клітинки
- тільки верхня/нижня межа для рядків
- товстіша лінія для заголовку таблиці
- комбінації без вертикальних меж тощо
Тому рамка клітинки збирається з чотирьох ліній як окремий компонент.
Як побудувати рамку з чотирьох ліній
- Створити компонент розміром 100×36 px.
- Додати лінію з довжиною по ширині компонента і розташувати її по нижньому краю — це bottom border, з горизонтальним стретчем і прив'язкою до низу.
- Задублювати цю лінію, повернути на 180°, прив'язати до верху — це top border.
- Ще одну копію повернути на -90°, розташувати ліворуч, задати вертикальний стретч — це left border.
- Останню копію повернути на 90° і поставити праворуч — right border.
- Для всіх ліній задати спільні базові параметри (у прикладі: сірий stroke 1 px зі стилю кольору).
Окремий нюанс, на якому акцентує авторка: у Figma лінія «росте» в один бік відносно своєї осі при зміні товщини stroke. Через це лінії спеціально обертаються, щоб зміна товщини завжди «йшла всередину» клітинки, а не «вилазила» назовні компонента.
Варіанти стилів рамок
Якщо в проєкті кілька стилів кордонів таблиці (наприклад, пунктир для тимчасових даних і суцільна для основних), для кожного стилю створюється окремий master компонента рамки. Базова структура — та сама, відрізняються лише:
- товщина ліній
- колір
- тип stroke (суцільна, пунктир, комбінована тощо)
Перевага цього підходу — будь-яка зміна в майстрі миттєво оновлює всі таблиці, де використано цю рамку. У кожній окремій клітинці можна задавати свої варіанти рамки, але базова логіка лишається спільною.
4. Контент клітинки: як зробити універсальні компоненти
Контент клітинки — найскладніша частина. Система повинна покривати різні типи вмісту:
- просто текст
- текст + іконка (зліва/справа, різне вирівнювання)
- чекбокси, перемикачі
- інші патерни з дизайн-системи (наприклад, теги, статуси, аватари з підписами)
Вимоги до контент-компонентів
Авторка формулює кілька важливих правил:
- компонент повинен легко тягнутися по ширині і висоті, щоб підлаштовуватися під клітинку
- мінімальний розмір компонента має бути меншим за стандартну висоту клітинки (особливо по висоті — з урахуванням відступів клітинки)
- усередині компонента не варто залишати зовнішні відступи, щоб не ламати вирівнювання
- фон компонента краще не задавати — ним керує фон клітинки
Контент-компоненти можна створювати поступово: спочатку простий текст, потім — іконка з текстом, далі складніші патерни. Головне — зберігати сумісність з базовим розміром клітинки.
Навіщо все це загортати в компоненти
Аргументація авторки проста: як і з фоном чи рамкою, компоненти економлять час. Заміна типу вмісту клітинки перетворюється на зміну вкладеного компонента, а не ручне редагування іконок, текстів і вирівнювання кожного разу.
5. Збірка клітинки як «молекули»
Після того, як фон, рамка і контент зроблені окремо, з них збирається клітинка — окремий компонент, який авторка називає «молекулою».
Структура компонента клітинки
- Нижній шар — фон
Фоновий компонент розтягується на всю клітинку з constraints «Left & Right» і «Top & Bottom». - Поверх нього — рамка
Компонент рамки з такими самими constraints, щоб лінії завжди йшли по краю клітинки, незалежно від її розміру. - Всередині — frame з контентом
Для контенту створюється додатковий frame, який задає відступи клітинки. Цей frame:
- тягнеться за розміром клітинки, але має внутрішні відступи (padding)
- містить всередині контент-компонент, який заповнює frame цілком
- не має власних зовнішніх відступів
У прикладі використано падінги по 4 px з усіх боків. Це значення «зашивається» в клітинку раз і назавжди. Його не вийде змінити для конкретної інстанції без створення нового типу клітинки.
Що робити, якщо потрібні інші відступи
Авторка пропонує обхідні варіанти:
- додати порожні колонки-клітинки фіксованої ширини (наприклад, 16 px) ліворуч і праворуч від основного стовпця, де потрібен додатковий відступ
- якщо дизайн дозволяє — заздалегідь закласти більші горизонтальні падінги в саму клітинку (як у Material Design, де клітинки таблиці мають 16 px падінги)
Ще одна технічна деталь: для клітинки і внутрішнього frame варто вимкнути «Clip content». Це потрібно для патернів на кшталт випадаючих списків, коли частина вмісту виходить за межі базової клітинки.
6. Набір типових клітинок для збирання таблиці
Щоб не вмикати/вимикати сторони рамки в кожній інстанції, авторка пропонує заздалегідь зробити набір майстер-компонентів клітинок з різними комбінаціями меж.
На основі однієї базової клітинки створюється ще вісім майстрів, у кожному з яких вимкнено певні сторони рамки. У підсумку виходить сітка варіантів:
- верхній ряд — для клітинок у верхній частині і середині таблиці
- нижній ряд — для нижнього краю, де важливо зберігати однакову товщину stroke без «подвоєння» ліній
Як цим користуватися на практиці
Авторка розглядає кілька типових сценаріїв:
- якщо у кожної клітинки повна рамка — достатньо чотирьох типів клітинок (кутові і середні)
- якщо є об'єднані клітинки або «дірки» в сітці бордерів — підключаються додаткові варіанти без певних сторін
- якщо вертикальні межі відсутні за дизайном — достатньо клітинок лише з горизонтальними лініями
Важливий наслідок: стилі бордерів перемикаються через заміну компонента клітинки, а не через ручне приховування шарів в інстанціях. Це зменшує ризик помилок і полегшує глобальні зміни.
7. Як змінювати таблицю після зборки
Коли таблиця вже складена з клітинок-компонентів, базові правки стають відносно простими.
Зміна висоти рядків
- Виділити всю таблицю.
- Змінити висоту клітинок через параметр H у правій панелі.
- Поставити вертикальний відступ між елементами в 0.
Зміна ширини колонок
- Виділити колонку і змінити її ширину.
- Підтягнути решту таблиці впритул.
- Скористатися опцією «Tidy Up» в панелі Alignment, щоб вирівняти сітку.
Авторка окремо попереджає, що групувати рядки й колонки небажано: при розтягуванні з групами легко отримати дробові значення ширини і висоти. Якщо не групувати, а тримати елементи на піксельній сітці, розміри клітинок зберігаються цілими.
Колір фону, тип рамки і контент змінюються через відповідні компоненти або через пов'язані з ними майстер-клітинки. Єдиний параметр, який не вийде оперативно змінити — падінги контенту, їх закладено в структурі клітинки.
8. Чому авторка наполягає на компонентах, а не override
Система з окремими компонентами фонів, рамок і контенту може здатися перевантаженою для невеликого проєкту з однією таблицею. В такому випадку авторка допускає спрощення — зробити один компонент клітинки й налаштовувати фон і рамку прямо в ньому.
Однак для командної роботи з бібліотекою компонентів і великою кількістю таблиць підхід «тільки компоненти, мінімум overrides» дає відчутну вигоду:
- зміни в майстрах гарантовано доходять до всіх використань
- менше «зламаних» інстанцій із нестандартними локальними правками
- легше створювати нові типи клітинок (наприклад, для header) як повноцінні майстри, а не як набір overrides
Авторка прямо не радить змінювати колір фону й рамок в інстанціях: такі overrides не отримають оновлення при зміні майстра, і потім доведеться все виправляти вручну.
9. Стани таблиці: default, hover, selected
Для інтерактивних таблиць доводиться думати ще й про стани. Клітинки, рядки й колонки зазвичай мають принаймні три:
- default
- hover
- selected
У невеликих проєктах стани можна задавати override всередині інстанцій: наприклад, просто міняти фон при hover. Але для великих систем, де зовнішній вигляд станів може змінюватися, авторка знову повертається до компонентного підходу:
- для кожного стану створити повний набір клітинок (ті ж вісім варіантів за рамками, якщо це потрібно)
- зробити окремі компоненти фону й рамки для кожного стану
Тут з'являється практичне обмеження: при заміні компонента клітинки на інший (наприклад, default → hover) є ризик втратити вміст клітинки, якщо тип вкладеного контент-компонента не збігається з майстром. Авторка вказує, що на момент написання статті це доводилося приймати як даність і оновлювати контент окремо.
У демонстраційному макеті авторка показує кілька реалізацій таблиць:
- повна схема з роздільними компонентами для стилів клітинок
- варіант, де клітинка — це просто обгортка для фон+рамка+контент
- спрощений варіант, де все, крім контенту, зібрано в одному компоненті клітинки
10. Як використовувати цю систему в реальних проєктах
Авторка описує два основні сценарії використання такої компонентної системи таблиць:
- Кілька проєктів на спільній бібліотеці
Можна створити локальну копію компонентів таблиць (включно з варіантами рамок і станів), адаптувати під конкретний проєкт і далі лише підключати необхідні контент-компоненти. - Один великий проєкт з безліччю різних таблиць
Компоненти масштабуються разом із проєктом: додаються нові типи клітинок, стани, варіанти бордерів, але базові принципи лишаються тими самими.
Фінальний макет з усіма прикладами можна завантажити за посиланням з оригінальної статті Smashing Magazine і використати для навчання або як відправну точку для власної дизайн-системи.
Корисні матеріали з оригінальної статті
- Atomic Design, Brad Frost
- How To Architect A Complex Web Table, Slava Shestopalov
- Creating Atomic Components In Figma, команда littleBits
- Figma Tables: Data Grid Design By A Single Cell-Component, Roman Kamushken
- Figma YouTube Channel — офіційні відео Figma
- Google Sheets Sync — плагін для підвантаження даних із Google Sheets у Figma; підхід з компонентами таблиць із цієї методики з ним сумісний, але доведеться акуратно іменувати текстові шари.
Джерело: Sasha Belichenko – Smashing Magazine. Дата оригіналу: 2019-09-25.