Concevez une fois, exécutez partout : un seul fichier d'interface utilisateur sur le Web, iOS et Android
Ce qu'il faut vraiment pour concevoir une seule fois et exécuter une interface utilisateur sur le Web, iOS et Android : mise en page et mouvements partagés, pièces spécifiques à la plate-forme, tests et emplacement de ExodeUI.
À retenir
Concevoir une fois, exécuter partout signifie qu'un fichier source décrit un composant d'interface utilisateur et que chaque plate-forme le lit avec un runtime, au lieu de reconstruire le même mouvement dans React, SwiftUI et Flutter. Cela fonctionne lorsque la disposition, les états, les mouvements et les entrées résident dans le fichier partagé, et reste honnête lorsque la navigation, l'accessibilité et les gestes du système restent spécifiques à la plate-forme. ExodeUI prend en charge ce modèle avec les packages d'exécution pour React, Vue, Svelte, Angular, Solid, React Native, SwiftUI et Flutter.
Ce que nécessite réellement « concevoir une fois, exécuter partout »
Cela nécessite plus qu’un bouton d’exportation. Le fichier partagé doit décrire comment le composant est disposé dans différentes tailles, à quoi il ressemble dans chaque état, comment il se déplace entre les états et comment l'application le pilote avec les entrées. Chaque plate-forme a également besoin d'un moteur d'exécution capable de lire le fichier et de connecter ces entrées à des événements réels. Si l’une de ces pièces manque, la promesse se transforme en un autre transfert.
Fichier partagé ou reconstruction par plateforme
La voie traditionnelle consiste à concevoir une fois et à reconstruire trois fois : Web dans CSS et JavaScript, iOS dans SwiftUI et Android dans Kotlin ou Flutter. Chaque reconstruction introduit de petites différences dans le timing, l'espacement et la gestion des gestes. Un itinéraire de fichiers partagé conserve la définition du composant au même endroit et permet à chaque plate-forme de la lire. Le compromis est qu'un environnement d'exécution se situe entre le fichier et la plate-forme, vous abandonnez donc un contrôle direct sur le rendu spécifique à la plate-forme.
Ce qui doit rester spécifique à la plateforme
Un composant partagé ne doit pas prétendre que chaque plateforme est identique. Les modèles de navigation, les gestes de retour, les boîtes de dialogue système, les autorisations et les API d'accessibilité diffèrent. Le fichier partagé doit posséder le composant visuel interactif ; l'application hôte doit posséder le chrome de la plate-forme et les contrôles sémantiques qui l'entourent. Par exemple, un bouton animé partagé peut se trouver à l’intérieur d’un élément de bouton natif qui expose le rôle et l’étiquette appropriés.
Comment fonctionnent les environnements d'exécution
Un moteur d'exécution lit le fichier, crée l'arborescence visuelle et la met à jour à mesure que les entrées changent. Le code de votre application définit les entrées telles que enfoncées, désactivées ou chargées, et écoute les événements tels que confirmer ou rejeter. Étant donné que la définition visuelle est constituée de données plutôt que de code écrit à la main par plate-forme, le moteur d'exécution est ce qui rend le même fichier portable. Le runtime est également une dépendance, alors mesurez son effet sur votre propre build au lieu de supposer qu'il est gratuit.
Tester le même fichier sur chaque environnement
Testez le fichier là où il s'exécutera, pas seulement dans l'éditeur. Vérifiez la mise en page dans les tailles les plus petites et les plus grandes prises en charge, vérifiez chaque état avec du contenu réel et testez séparément la saisie tactile, la souris et le clavier. Vérifiez ensuite l'accessibilité : ordre de mise au point, étiquettes, mouvement réduit et comportement du lecteur d'écran. Un fichier partagé réduit la dérive visuelle, mais cela ne supprime pas la nécessité de tester chaque plateforme.
Où s'adapte ExodeUI
ExodeUI stocke un composant dans un fichier .exode ouvert et fournit des packages d'exécution pour React, Vue, Svelte, Angular, Solid, React Native, SwiftUI et Flutter. Le fichier peut inclure une présentation et des points d'arrêt, des chronologies, des machines à états, la physique du printemps, des entrées et des événements. Le même fichier peut être modifié dans le navigateur ou dans l'éditeur de bureau, et les outils de codage d'IA peuvent fonctionner dessus via le serveur MCP.
Quand ne pas utiliser un fichier partagé
Un fichier partagé ne convient pas lorsque l'interface dépend fortement d'API de plate-forme uniquement, lorsque vous avez besoin d'un contrôle au niveau des pixels sur le rendu natif ou lorsque le composant est principalement une vidéo ou une scène 3D. C’est également une mauvaise solution si votre équipe ne peut pas tester chaque cible. Dans ces cas-là, le code spécifique à la plateforme constitue le choix honnête, et un fichier partagé ne doit couvrir que les parties qui en bénéficient réellement.
Extrait d’implémentation en production
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()}
/>
);
}Principes clés à retenir
- Concevoir une fois et exécuter partout nécessite une mise en page, des états, des mouvements et des entrées partagés, ainsi qu'un environnement d'exécution par plate-forme.
- Les API de navigation, d'autorisations et d'accessibilité doivent rester spécifiques à la plateforme
- Un runtime est une dépendance ; mesurer son effet sur votre build
- Testez chaque cible pour la mise en page, la saisie, le mouvement et l'accessibilité
- ExodeUI fournit des environnements d'exécution pour React, Vue, Svelte, Angular, Solid, React Native, SwiftUI et Flutter.