Спроектируйте один раз, работайте повсюду: один файл пользовательского интерфейса для Интернета, iOS и Android
Что на самом деле нужно, чтобы один раз спроектировать и запустить пользовательский интерфейс в Интернете, iOS и Android: общий макет и движение, детали, специфичные для платформы, тестирование и то, где подходит ExodeUI.
Главное
Проектирование один раз, запуск повсюду означает, что один исходный файл описывает компонент пользовательского интерфейса, и каждая платформа воспроизводит его во время выполнения, вместо того, чтобы перестраивать одно и то же движение в React, SwiftUI и Flutter. Он работает, когда макет, состояния, движение и ввод данных находятся в общем файле, и остается честным, когда навигация, доступность и системные жесты остаются специфичными для платформы. ExodeUI поддерживает эту модель с помощью пакетов времени выполнения для React, Vue, Svelte, Angular, Solid, React Native, SwiftUI и Flutter.
Что на самом деле требует принцип «разработай один раз, работай везде»
Для этого требуется нечто большее, чем просто кнопка экспорта. Общий файл должен описывать, как компонент размещается в разных размерах, как он выглядит в каждом состоянии, как он перемещается между состояниями и как приложение управляет им с помощью входных данных. Каждой платформе также необходима среда выполнения, которая может воспроизводить файл и связывать эти входные данные с реальными событиями. Если какая-либо из этих частей отсутствует, обещание превращается в еще одну передачу.
Общий файл или перестройка для каждой платформы
Традиционный путь — один раз спроектировать и трижды перестроить: веб — в CSS и JavaScript, iOS — в SwiftUI и Android — в Kotlin или Flutter. При каждой перестройке возникают небольшие различия во времени, интервале и обработке жестов. Общий маршрут к файлу хранит определение компонента в одном месте и позволяет каждой платформе воспроизводить его. Компромисс заключается в том, что среда выполнения находится между файлом и платформой, поэтому вы отказываетесь от прямого контроля над рендерингом для конкретной платформы.
Что должно оставаться привязанным к платформе
Общий компонент не должен делать вид, что все платформы одинаковы. Шаблоны навигации, жесты назад, системные диалоги, разрешения и API специальных возможностей различаются. Общий файл должен владеть интерактивным визуальным компонентом; хост-приложение должно владеть платформенным Chrome и семантическими элементами управления вокруг него. Например, общая анимированная кнопка может находиться внутри собственного элемента кнопки, который предоставляет правильную роль и метку.
Как работают среды выполнения
Среда выполнения считывает файл, строит визуальное дерево и обновляет его по мере изменения входных данных. Код вашего приложения устанавливает такие входные данные, как нажатие, отключение или загрузка, и прослушивает такие события, как подтверждение или отклонение. Поскольку визуальное определение — это данные, а не рукописный код для каждой платформы, именно среда выполнения делает тот же файл переносимым. Среда выполнения также является зависимостью, поэтому измеряйте ее влияние на свою собственную сборку, а не предполагайте, что она бесплатна.
Тестирование одного и того же файла в каждой среде
Тестируйте файл там, где он будет запускаться, а не только в редакторе. Проверьте макет наименьшего и наибольшего поддерживаемых размеров, сверьте каждое состояние с реальным содержимым и протестируйте сенсорный ввод, ввод с помощью мыши и клавиатуры отдельно. Затем проверьте доступность: порядок фокуса, метки, ограничение движения и работу программы чтения с экрана. Общий файл уменьшает визуальный дрейф, но не устраняет необходимости тестировать каждую платформу.
Где подходит ExodeUI
ExodeUI хранит компонент в открытом файле .exode и предоставляет пакеты времени выполнения для React, Vue, Svelte, Angular, Solid, React Native, SwiftUI и Flutter. Файл может включать макет и точки останова, временные шкалы, конечные автоматы, физику пружин, входные данные и события. Один и тот же файл можно редактировать в браузере или настольном редакторе, а инструменты ИИ-кодирования могут работать с ним через сервер MCP.
Когда не следует использовать один общий файл
Общий файл плохо подходит, когда интерфейс сильно зависит от API-интерфейсов только для платформы, когда вам нужен контроль на уровне пикселей над собственным рендерингом или когда компонент в основном представляет собой видео или 3D-сцену. Это также плохо подходит, если ваша команда не может протестировать каждую цель. В таких случаях честным выбором будет код, специфичный для платформы, а общий файл должен охватывать только те части, которые действительно извлекают из него пользу.
Пример реализации для продакшена
import { ExodeUICanvas } from 'exodeui';
// The same component file can be played by the runtime your app already uses.
// Web, React Native, SwiftUI and Flutter packages read the same .exode source.
export function ShareSheet({ open, progress, onClose }) {
return (
<ExodeUICanvas
src="/share_sheet.exode"
inputs={{ open, progress }}
onTrigger={(name) => name === 'close' && onClose()}
/>
);
}Ключевые принципы
- Проектирование один раз и запуск повсюду требует общего макета, состояний, движения и ввода, а также среды выполнения для каждой платформы.
- API навигации, разрешений и доступности должны оставаться специфичными для платформы.
- Среда выполнения — это зависимость; измерить его влияние на вашу сборку
- Проверьте каждую цель на расположение, ввод, движение и доступность.
- ExodeUI предоставляет среды выполнения для React, Vue, Svelte, Angular, Solid, React Native, SwiftUI и Flutter.