Comments 9
Спасибо за статью! Если авто генерация будет корректно работать только на визуальном представлении, а для каждой новой фичи в компоненте необходимо будет улучшать генератор индивидуального компонента, не усложняет ли это процесс?
Или для вас доработка генераторов выходит быстрее, чем доработка его представления непосредственно в storybook?
Как мне кажется, большая часть изменений приходится на новые фичи или я ошибаюсь?
Привет! Спасибо! Хороший вопрос!)
Поскольку на данный момент мы говорим о довольно простых компонентах (например, радиобаттон, чекбокс, кнопки, теги, статусы и т.п.), то вероятность их принципиальной доработки невелика. У таких компонентов есть предел их конфигурации, он вполне понятный и уже заложен в логику генератора.
Например, если мы захотим поменять галочку внутри чекбокса на что-то другое или добавить новый размер или тип кнопки, то сделаем это за минуту без код-ревью и дизайн-надзора, так как генератор уже заточен под такие изменения.
При обычном подходе процесс был бы существенно длиннее — дизайнер бы обрисовал вариант компонента, передал его разработчику, разработчик бы вручную допилил компонент (с рисками ошибиться при переносе, так как все мы люди), а потом еще дизайнеру нужно было бы прийти и посмотреть, всё ли корректно реализовано.
Кроме того, если нам, например, в другом проекте нужна та же кнопка, только с другими типами, размерами, состояниями, то мы берем за основу текущий компонент в Figma, дизайнер его модифицирует, а генератор генерирует. Frontend-разработчику не нужно даже вникать и смотреть компонент в Figma, он просто на своей стороне нажимает копку и получает полноценный компонент, 100%-но соответствующий тому, что нарисовано в дизайне.
И еще момент. Если нужно создать новый компонент, работающий по принципу того компонента, который уже генерируется, — это тоже происходит за минуту. Например, на основе компонента status (по сути цветная плашка с текстом) дизайнер за пару минут создает компонент tag (тоже по сути цветная плашка с текстом, просто с другими параметрами), и разработчику опять же ничего не нужно, кроме как нажать на кнопку генератора.
Это всё значительно быстрее и надежнее, чем доработка или создание компонента вручную. Плюс мы получаем 100%-ную синхронизацию навсегда — генерируемые компоненты никогда не разойдутся с дизайном.
Но если говорить о сложных компонентах, то мы их не генерируем как раз потому, что дописать их вручную или взять из открытой библиотеки проще, чем дописать под это генератор.
Заоупенсорсить не планируете?
Спасибо за статью!
Вообще да, поддержка дизайн-систем из Фигмы на фронте это та еще боль - но с интеграцией переменных летом у нас дела пошли существенно лучше. Не идеально, конечно - главным образом из-за бета-вости этого функционала, переменных под параметры шрифтов и текстов очень сильно не хватает (хотя вроде обещают в ближайшее время подвезти) - все-таки именно от кегля и высоты строки довольно много других компонентов может быть увязано.
Плюс, хорошая, стройная дизайн-система в идеале должна быть максимально атомарной, с компонентами с большим количеством уровней вложенности - но в Фигме это, к сожалению, ломается о программные нюансы (при переключении стейтов у компонентов с вложенными атомами могут ломаться стили - по типу заливки и т.д.) - это тоже существенно портит общий опыт работы и заставляет применять разного рода костыли.
Что касается переиспользования дизайн-системы мы практикуем трехуровневый подход к формированию переменных, условно: root, layout, assets. Переменные в двух последних всегда ссылаются на root и уникальные значения там есть только для таких же уникальных компонентах. Это позволяет довольно быстро портировать базовые UI-киты на новые продукты и поддерживать некую общую нотацию между дизайнерами и разработчиками.
Почти сразу, как перешли на переменные, столкнулись с проблемой экспорта их в разработку - поэтому с командой сделали плагин для умного экспорта библиотек переменных в CSS/SCSS с поддержкой сортировки переменных по папкам и другими полезными плюшками (плагин абсолютно бесплатный): https://www.figma.com/community/plugin/1260472771849439434/advanced-variable-export-ave
И сейчас на его основе и на основе сформированных в команде нотаций по работе над дизайн-системой работаем над генератором компонентов - и видимо, нам потребуется как-то это все адоптировать под реалии свежего обновления ДевМода, которое явно усложнило жизнь большому числу команд, особенно небольших :/
Удивительно что за последние 20-30 лет фундаментально никто не смог эту проблему решить в той степени чтобы больше не касаться... В своё время в Фотошопе с состояниями слоёв и смарт-объектами эмулировали компоненты, потом пришёл XD и казалось ну вот Adobe максимально близко к решению этой проблемы, и с их мощностями рано или поздно получится сделать единую систему в которой дизайн и фронт будут взаимно интегрированы, но и тут даже разочарование. Я уже молчу про всякие Zeplin + Sketch или Avocode... Теперь Figma со своим dev-mode вплотную приближается к решению проблемы но вот как будто всё равно уходит куда-то не туда, и приходится изобретать свои велосипеды.
Мне интересно получится ли дожить до того момента когда какое-нибудь действительно универсальное решение позволит без тонны костылей решать проблемы интеграции дизайна с фронтом и делать это предсказуемо и единообразно...
Спасибо за комментарий! Здорово, что вы подсветили этот интересный вопрос!
Да, кажется, что сфера уже давно топчется на пороге такого прорыва, а он всё не происходит и не происходит🤷🏼♀️
Максимально близко к этому в своё время пытались подойти именно Adobe со своим XD в том эпохальном представлении на Adobe MAX 2015 (Design with Data опередил своё время и это казалось просто нереально круто).
Sketch.app при всём своём очаровании ушел куда-то совсем не туда.
Был ещё интересный Invision app с большими амбициями (если не изменяет память то очень долго обещали прорыв со своей STUDIO, но по факту и половину фишек не реализовали от того что хотели)...
Эх, сейчас уже много чего забылось и вообще сферу деятельности поменял, а надо было заметки делать чтобы потом книгу по истории инструментов для веб-дизайна написать.
Ну может хоть какие-нибудь VK или Yandex чего придумают. Проблема в том что сейчас технологии позволяют сделать убер-инструмент, но вот сложность его проектирования во многом зависит ещё и от состояния обоих отраслей (дизайн и фронт), а в них сейчас хоть уже и не "дикий запад", но от состояния стабильности набора технологических решений очень далеко. Кроме того ещё сама система веб-стандартов — это бегущая курица без головы — вот какой-нибудь Draft стандарта например по leading trim уже как с апреля 23-го существует в рамках CSS Inline Layout Module Level 3, но ещё нигде не поддерживается, а заботливые разработчики Figma делают кнопочку в свойствах тестового блока "Vertical trim", и никто не пишет что напрямую это не стандартная фишка и надо её адаптировать, а дизайнер уже отчитался что все макеты согласованы и надо верстать, а все отступы из-за этого по факту нужно пересчитывать. Понятно что это частный случай и можно сказать мол один раз наступили, теперь делайте "так", но вот таких моментов десятки, и чтобы всё работало как полагается — на уровне индустрии нужна огромная бизнес-воля не только в виде ресурсов это реализовать но также внедрить, а главное — донести до широкой общественности как теперь надо пользоваться.
Прошу прощения что несколько сумбурно, но это уже эмоциональная сторона проявляется на фоне разочарования современным вебом, который при всём своём великом разнообразии больше похож на первичный бульон в котором только должна зародиться более сложная форма живой материи.
/* тут должна быть картинка про то что когда-то трава была зеленее, мы — моложе, а для счастья хватало Фотошопа с одной стороны и jQuery с другой. */
Figma to Frontend: как мы автоматически синхронизируем дизайн и код