Вы, вероятно, пробовали один из инструментов Figma-to-code, которые обещают превратить ваши проекты в рабочий React или HTML одним щелчком мыши. Они кажутся идеальным ярлыком, предлагающим возможность пропустить повторяющуюся работу по макетированию и перейти непосредственно от дизайна к продукту.
Но скорость часто достигается за счет структуры. Экспортированный код выглядит правильно при предварительном просмотре, но на самом деле он статичен, повторяется и его сложно поддерживать. Стили жестко запрограммированы, компоненты объединены в общие теги
Давайте разберемся, почему это происходит и как это исправить. Вы увидите, что на самом деле генерируют инструменты Figma-to-code, почему их выходные данные не подходят для производства и как компонуемая архитектура помогает превратить экспорт проектов в модульные, готовые к производству компоненты.
Что генерируют инструменты Figma-to-Code
Основная проблема инструментов Figma-to-code заключается в том, что они копируют визуальный макет дизайна, а не его базовую структуру. Они рассматривают каждый элемент как уникальную форму вместо того, чтобы распознавать шаблоны или повторно используемые компоненты.
Чтобы увидеть, как большинство инструментов преобразования Figma в код ведут себя на практике, начните с простой конструкции информационной панели от сообщества Figma, такой как эта минимальная финансовая панель. Экспортируйте его в код, используя любой популярный плагин Figma-to-code, который утверждает, что генерирует адаптивный код.
Через несколько секунд вы получите работающий предварительный просмотр, который выглядит впечатляюще. Макет выровнен, текст отображается аккуратно, а кнопки реагируют на взаимодействие.
Создан предварительный просмотр минимального дизайна информационной панели.
Но при проверке сгенерированного кода ограничения становятся очевидными. Макет не является адаптивным, а элементы, которые должны быть интерактивными, например кнопки или нумерация страниц, отображаются как общие элементы
Например, было создано:
1234567
Вместо чего-то более близкого к:
123
Даже компоненты Figma, которые кажутся интерактивными, такие как элементы выбора или разбивки по страницам, не содержат логики. Они представляют собой заполнители без управления поведением или состоянием.
Это подчеркивает более глубокую проблему, связанную с тем, что эти инструменты повторяют больше внешний вид, чем архитектуру. Они могут воспроизводить поверхность пользовательского интерфейса, но не отражают его состав, поведение или намерения.
Почему код, сгенерированный Figma, терпит неудачу в производстве
Помимо структуры и отзывчивости, сгенерированный код также дает сбои, которые затрудняют совместную работу и долгосрочное использование. Они включают в себя:
Это не связано с вашей системой дизайна
Системы проектирования существуют для обеспечения согласованности. Они дают вам токены для интервала, типографики и цвета, а также определяют повторно используемые компоненты, такие как кнопки, карточки и модальные окна. Инструменты Figma-to-code игнорируют все это. В экспортированной информационной панели ни один из стилей не был связан с токенами дизайна или системными переменными. Например, кнопка «Новый депозит» не была сопоставлена ни с одним существующим компонентом; вместо этого он был перестроен с нуля. Со временем такой подход может создать теневую систему несовпадающих компонентов, которая отойдет от вашей реальной системы проектирования.
Нет отслеживания версий
Когда вы экспортируете код из плагина Figma-to-code, он выглядит как дамп одного файла. Нет никакой истории того, как развивался дизайн или кто что изменил. Это делает практически невозможным отследить проблему пользовательского интерфейса до ее источника. В производственных средах команды полагаются на историю git и управление версиями дизайна для безопасного сотрудничества. Без этой ссылки каждый экспорт становится замороженным снимком, который нельзя откатить или сравнить. Разработчики часто удаляют выходные данные и начинают заново с ручного кодирования, чтобы избежать беспорядка.
Трудно подобрать другого разработчика
Даже если вы сами понимаете сгенерированный код, другой разработчик, присоединившийся к проекту, может этого не понять. Экспорт не дает четких границ компонентов, определений свойств (свойств) и объяснений того, как его следует использовать. Не существует встроенной документации, показывающей ожидаемые состояния или варианты. Без этого контекста новому разработчику приходится перепроектировать как замысел проекта, так и особенности кода, прежде чем вносить даже небольшие изменения. В командной работе отсутствие ясности быстро становится убийцей производительности.
Именно из-за этих ограничений большинство команд в конечном итоге полностью отказываются от кода, сгенерированного инструментами Figma-to-code. Но что, если рабочий процесс начнется с возможности компоновки вместо статической разметки?
Как преобразовать проекты Figma в готовый к использованию код
Чтобы превратить экспорт дизайна в поддерживаемый код, начните с импорта той же панели инструментов Figma, которая использовалась ранее, в Hope AI. Инструмент сначала проанализирует макет и иерархию, сопоставив дизайн с деревом компонентов, в котором выделяются повторно используемые шаблоны, такие как кнопки, карточки и формы ввода.
Надеюсь, что этап анализа ИИ, показывающий, что он интерпретирует запрос пользователя перед генерацией кода.
На этом предварительном этапе структура обретает форму. Вы просматриваете предлагаемую архитектуру, подтверждаете взаимосвязи между компонентами и при необходимости корректируете именование или группировку. Этот процесс меняет обычный рабочий процесс от проектирования к коду, гарантируя, что структура идет впереди, а код следует за ней.
Надеюсь, что этап анализа ИИ, показывающий, что он интерпретирует запрос пользователя перед генерацией кода.
После утверждения структуры Hope AI генерирует компоненты и создает интерактивную демонстрацию. Каждый элемент использует правильную семантику HTML. Кнопки определяются как элементы
Если подобные компоненты уже существуют где-либо в вашем проекте или компании, Hope AI обнаружит их и повторно использует вместо дублирования новых. Это сохраняет вашу дизайн-систему чистой и последовательной. За кулисами код организован в виде Bit-компонентов, каждый из которых имеет реквизиты, тесты, README и пример живой композиции. Вы также можете расширить их для публикации определенных компонентов в вашей дизайн-системе.
Представление на информационной панели компонентов, созданных Hope AI, с прилагаемой документацией
Сгенерированные компоненты готовы к управлению версиями и могут использоваться совместно между проектами или командами. Каждый из них независим и доступен для обнаружения в реестре компонентов, что значительно упрощает совместную работу и масштабирование.
Помимо семантики и структуры, компонуемая архитектура Hope AI еще более эффективна в производственных рабочих процессах.
Почему рабочий процесс на базе искусственного интеллекта Bit Cloud масштабируется в производстве
Реальная ценность компонуемого рабочего процесса проявляется в том, как команды создают, поддерживают и масштабируют приложения. Некоторые области включают в себя:
- Повторное использование в проектах: Компоненты упаковываются как версии модулей, которые можно импортировать в любой проект. Ваша команда может избежать повторного создания одной и той же кнопки или карточки несколько раз, обеспечивая единообразие поведения и более быструю доставку.
- Цикл обратной связи от проекта к разработке: Поскольку компоненты находятся в общем реестре, дизайнеры могут просматривать существующие компоненты перед созданием новых шаблонов. Это сокращает циклы передачи управления, уменьшает дублирование и обеспечивает согласованность дизайна и кода.
- История версий и отслеживаемость: Каждый компонент имеет историю версий. Вы можете увидеть, когда и почему что-то изменилось, и безопасно откатиться назад. Это заменяет статический и одноразовый характер экспорта Figma совместным рабочим процессом.
- Готовность к производству с самого начала: Сгенерированные компоненты используют семантический HTML, включают тесты и соответствуют стандартам доступности. Вы можете отправить их напрямую, вместо того, чтобы переписывать или отлаживать сгенерированный код.
Рабочий процесс Hope AI демонстрирует, что проектирование в код может работать в производстве, но только в том случае, если рабочий процесс учитывает то, как команды создают и поддерживают программное обеспечение.
Подведение итогов
Большинство инструментов Figma-to-code экспортируют статическую разметку, которая отражает дизайн, но не работает при производстве. Выходные данные являются жесткими, неструктурированными и не связаны с вашей системой, поэтому команды часто отбрасывают их и перестраивают с нуля. Компонуемый рабочий процесс, такой как Bit’s Hope AI, идет по другому пути. Проекты разбиваются на повторно используемые компоненты с реквизитами, семантическим HTML, тестами и историей версий. Вместо одноразового кода вы получаете строительные блоки, которые естественным образом вписываются в реальную кодовую базу и могут масштабироваться вместе с вашим продуктом.
Инженерная оценка всегда будет необходима, но начало работы с готовыми к производству компонентами дает командам серьезное преимущество. Это уменьшает дублирование, улучшает сотрудничество и создает общий источник истины для проектирования и разработки.
Хотите увидеть этот рабочий процесс в действии? Запустите проект с помощью Hope AI и получите готовые к работе компоненты, которые вы сможете редактировать, совместно использовать и повторно использовать в разных проектах.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Темитопе Оеделе — разработчик программного обеспечения и технический писатель. Ему нравится писать о том, что он узнал и испытал. Узнайте больше от Темитопе Ойеделе
