Einmal entwerfen, überall ausführen: Eine UI-Datei für Web, iOS und Android
Was es wirklich braucht, um einmal eine Benutzeroberfläche zu entwerfen und auf Web, iOS und Android auszuführen: gemeinsames Layout und Bewegung, plattformspezifische Teile, Tests und wo ExodeUI passt.
Kernaussage
Einmal entwerfen, überall ausführen bedeutet, dass eine Quelldatei eine UI-Komponente beschreibt und jede Plattform sie mit einer Laufzeit abspielt, anstatt dieselbe Bewegung in React, SwiftUI und Flutter neu zu erstellen. Es funktioniert, wenn Layout, Zustände, Bewegungen und Eingaben in der freigegebenen Datei gespeichert sind, und es bleibt ehrlich, wenn Navigation, Zugänglichkeit und Systemgesten plattformspezifisch bleiben. ExodeUI unterstützt dieses Modell mit Laufzeitpaketen für React, Vue, Svelte, Angular, Solid, React Native, SwiftUI und Flutter.
Was „Einmal entwerfen, überall ausführen“ tatsächlich erfordert
Es erfordert mehr als eine Exportschaltfläche. Die freigegebene Datei muss beschreiben, wie die Komponente in verschiedenen Größen angeordnet ist, wie sie in den einzelnen Zuständen aussieht, wie sie sich zwischen den Zuständen bewegt und wie die App sie mit Eingaben steuert. Jede Plattform benötigt außerdem eine Laufzeitumgebung, die die Datei abspielen und diese Eingaben mit realen Ereignissen verbinden kann. Wenn eines dieser Teile fehlt, wird das Versprechen zu einer weiteren Übergabe.
Gemeinsam genutzte Datei vs. Neuaufbau pro Plattform
Der traditionelle Weg besteht darin, einmal zu entwerfen und dreimal neu zu erstellen: Web in CSS und JavaScript, iOS in SwiftUI und Android in Kotlin oder Flutter. Bei jedem Neuaufbau gibt es kleine Unterschiede in Timing, Abstand und Gestenhandhabung. Bei einer gemeinsam genutzten Dateiroute bleibt die Komponentendefinition an einem Ort und kann von jeder Plattform abgespielt werden. Der Nachteil besteht darin, dass eine Laufzeit zwischen der Datei und der Plattform liegt, sodass Sie auf eine gewisse direkte Kontrolle über das plattformspezifische Rendering verzichten.
Was sollte plattformspezifisch bleiben?
Eine gemeinsame Komponente sollte nicht so tun, als ob jede Plattform gleich wäre. Navigationsmuster, Zurück-Gesten, Systemdialoge, Berechtigungen und Barrierefreiheits-APIs unterscheiden sich. Die freigegebene Datei sollte Eigentümer der interaktiven visuellen Komponente sein; Die Host-App sollte Eigentümer der Plattform Chrome und der sie umgebenden semantischen Steuerelemente sein. Beispielsweise kann sich eine gemeinsam genutzte animierte Schaltfläche in einem nativen Schaltflächenelement befinden, das die richtige Rolle und Bezeichnung anzeigt.
Wie Laufzeiten funktionieren
Eine Laufzeitumgebung liest die Datei, erstellt den visuellen Baum und aktualisiert ihn, wenn sich die Eingaben ändern. Ihr Anwendungscode legt Eingaben wie „Gedrückt“, „Deaktiviert“ oder „Laden“ fest und wartet auf Ereignisse wie „Bestätigen“ oder „Entlassen“. Da es sich bei der visuellen Definition um Daten und nicht um handgeschriebenen Code pro Plattform handelt, ist es die Laufzeit, die dieselbe Datei portierbar macht. Die Laufzeit ist ebenfalls eine Abhängigkeit. Messen Sie daher ihre Auswirkung auf Ihren eigenen Build, anstatt davon auszugehen, dass sie kostenlos ist.
Testen derselben Datei in jeder Umgebung
Testen Sie die Datei dort, wo sie ausgeführt werden soll, nicht nur im Editor. Überprüfen Sie das Layout in den kleinsten und größten unterstützten Größen, überprüfen Sie jeden Status mit echten Inhalten und testen Sie Touch-, Maus- und Tastatureingaben separat. Überprüfen Sie dann die Barrierefreiheit: Fokusreihenfolge, Beschriftungen, reduzierte Bewegung und Verhalten des Bildschirmlesers. Eine gemeinsam genutzte Datei verringert die visuelle Abweichung, beseitigt jedoch nicht die Notwendigkeit, jede Plattform zu testen.
Wo ExodeUI passt
ExodeUI speichert eine Komponente in einer geöffneten .exode-Datei und stellt Laufzeitpakete für React, Vue, Svelte, Angular, Solid, React Native, SwiftUI und Flutter bereit. Die Datei kann Layout und Haltepunkte, Zeitleisten, Zustandsautomaten, Federphysik, Eingaben und Ereignisse enthalten. Dieselbe Datei kann im Browser oder Desktop-Editor bearbeitet werden, und KI-Codierungstools können über den MCP-Server daran arbeiten.
Wann Sie eine freigegebene Datei nicht verwenden sollten
Eine freigegebene Datei ist schlecht geeignet, wenn die Schnittstelle stark von plattformspezifischen APIs abhängt, wenn Sie eine Kontrolle auf Pixelebene über das native Rendering benötigen oder wenn es sich bei der Komponente hauptsächlich um ein Video oder eine 3D-Szene handelt. Es ist auch schlecht geeignet, wenn Ihr Team nicht jedes Ziel testen kann. In solchen Fällen ist plattformspezifischer Code die ehrliche Wahl, und eine gemeinsam genutzte Datei sollte nur die Teile abdecken, die wirklich davon profitieren.
Produktionsnahes Implementierungsbeispiel
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()}
/>
);
}Wichtige Prinzipien
- Einmal entwerfen und überall ausführen, erfordert gemeinsames Layout, gemeinsame Zustände, Bewegungen und Eingaben sowie eine Laufzeit pro Plattform
- Navigations-, Berechtigungen- und Barrierefreiheits-APIs sollten plattformspezifisch bleiben
- Eine Laufzeit ist eine Abhängigkeit; Messen Sie die Auswirkung auf Ihren Build
- Testen Sie jedes Ziel auf Layout, Eingabe, Bewegung und Zugänglichkeit
- ExodeUI bietet Laufzeiten für React, Vue, Svelte, Angular, Solid, React Native, SwiftUI und Flutter