Один файл для дизайна пользовательского интерфейса: как один открытый файл заменяет передачу управления
Рабочий процесс проектирования пользовательского интерфейса в одном файле сохраняет макет, состояния, движение, логику и привязки данных в одном открытом файле. Что он меняет, что не решает и как это использует ExodeUI.
Главное
Рабочий процесс проектирования пользовательского интерфейса с одним файлом сохраняет макет, состояния взаимодействия, движение, логику и привязки данных компонента в одном открытом файле, а не распределяет их по файлу дизайна, прототипу и базе кода. Файл становится тем, что редактируют дизайнеры, разработчики просматривают, а агенты ИИ могут читать. ExodeUI использует эту модель: файл .exode описывает компонент, а пакеты времени выполнения воспроизводят его в приложении.
Что означает «один файл» в дизайне пользовательского интерфейса?
Это означает, что компонент имеет один авторитетный источник. Монтажные области, состояния наведения и нажатия, значения пружин, условия, определяющие, какое состояние будет следующим, а также входные данные, которые ваше приложение может установить, — все это находится в одном документе. В отдельной записке о передаче ничего важного не оставлено. При изменении файла изменяется и компонент.
Проблема передачи управления решается одним файлом
Обычно дизайнер предоставляет статический файл, прототип и письменное описание движения. Разработчик перестраивает это движение в коде, и обе версии сразу же расходятся. Рабочий процесс с одним файлом исключает этап перестроения для частей, которые охватывает файл. Это не устраняет необходимости рецензирования, но дает рецензентам один и тот же артефакт вместо двух его описаний.
Что входит в открытый файл дизайна пользовательского интерфейса
Точная структура зависит от инструмента, но полезный файл охватывает одни и те же задачи:
- Макет, включая точки останова и способ перекомпоновки компонента.
- Состояния взаимодействия, такие как простой, наведение, нажатие, загрузка, успех и ошибка.
- Движение, включая временные рамки, физику пружин и переходы между состояниями.
- Логика и условия, определяющие, какое состояние активно
- Входные данные и события, позволяющие коду приложения управлять компонентом и реагировать на него.
- Привязки данных для значений, поступающих из приложения во время выполнения.
Что остается за пределами файла
Файл компонента — это не все приложение. Маршрутизация, аутентификация, получение данных, разрешения, аналитика и оболочка специальных возможностей интерактивного элемента управления остаются в вашей кодовой базе. Навигация по платформе и системные жесты обычно также зависят от платформы. Четкое понимание этих границ имеет значение: рабочий процесс с одним файлом легче внедрить, когда он обрабатывает интерактивный компонент и оставляет проблемы приложения на усмотрение приложения.
Может ли команда просмотреть один файл?
Да, если формат открытый и читаемый. ExodeUI хранит компонент в открытом файле .exode JSON, поэтому изменения можно сравнивать, просматривать и хранить в системе контроля версий. Это практическое преимущество перед двоичными файлами проекта: рецензент может увидеть, что изменилось в файле, а инструмент кодирования AI может прочитать это без специального декодера. Открытость не отвечает на все вопросы управления, но делает обзор возможным.
Как ExodeUI использует один файл
В ExodeUI файл .exode может содержать макет, точки останова, временные шкалы, конечные автоматы, физику пружин, логику, входные данные и привязки данных. Пакеты времени выполнения воспроизводят файл в форматах React, Vue, Svelte, Angular, Solid, React Native, SwiftUI и Flutter. Ваш код передает входные данные и получает события обратно вместо того, чтобы повторять движение. Тот же файл можно открыть в браузере или настольном редакторе, а инструменты ИИ-кодирования могут редактировать его через сервер MCP.
Когда один файл — неправильный выбор
Один файл плохо подходит для работы, которая не является интерактивным компонентом: длинное видео, тяжелые 3D-сцены или доска произвольной формы для раннего формирования идей. Это также плохо подходит, когда у команды нет процесса проверки и ей нужен один файл для обеспечения соблюдения стандартов. Такой формат может облегчить хорошую практику. Оно не может заменить практику.
Пример реализации для продакшена
import { ExodeUICanvas } from 'exodeui';
// One component, one file. Layout, states, motion and logic stay in the
// .exode file; the app only supplies inputs and handles events.
export function CheckoutButton({ loading, disabled, onComplete }) {
return (
<ExodeUICanvas
src="/checkout_button.exode"
inputs={{ loading, disabled }}
onTrigger={(name) => name === 'complete' && onComplete()}
/>
);
}Ключевые принципы
- Рабочий процесс в одном файле сохраняет макет, состояния, движение, логику и входные данные в одном авторитетном документе.
- Он удаляет этап перестройки интерактивного компонента, а не необходимость проверки.
- Проблемы приложения, такие как маршрутизация, аутентификация и получение данных, остаются в вашей кодовой базе.
- Открытый исходный файл JSON может быть дифференцирован, версионирован и прочитан инструментами искусственного интеллекта.
- ExodeUI воспроизводит один и тот же файл .exode во время выполнения в веб-платформах, мобильных устройствах и настольных системах.