Un seul fichier pour la conception de l'interface utilisateur : comment un seul fichier ouvert remplace le transfert
Un flux de travail de conception d'interface utilisateur dans un seul fichier conserve la disposition, les états, les mouvements, la logique et les liaisons de données dans un seul fichier ouvert. Ce que cela change, ce qu'il ne résout pas et comment ExodeUI l'utilise.
À retenir
Un workflow de conception d'interface utilisateur dans un seul fichier conserve la disposition, les états d'interaction, le mouvement, la logique et les liaisons de données d'un composant dans un seul fichier ouvert au lieu de les répartir sur un fichier de conception, un prototype et une base de code. Le fichier devient l’élément que les concepteurs modifient, que les développeurs examinent et que les agents d’IA peuvent lire. ExodeUI utilise ce modèle : un fichier .exode décrit un composant et les packages d'exécution le lisent dans l'application.
Que signifie « un fichier » dans la conception de l'interface utilisateur ?
Cela signifie que le composant a une source faisant autorité. Les plans de travail, les états de survol et d'appui, les valeurs de ressort, les conditions qui décident quel état vient ensuite et les entrées que votre application peut définir sont tous présents dans le même document. Rien d’important n’est laissé dans une note de transfert distincte. Lorsque le fichier change, le composant change.
Le problème de transfert qu'un fichier supprime
Lors d'un transfert typique, le concepteur fournit un fichier statique ainsi qu'un prototype et une description écrite du mouvement. Un développeur reconstruit ce mouvement dans le code et les deux versions dérivent immédiatement. Un flux de travail à fichier unique supprime l’étape de reconstruction pour les parties couvertes par le fichier. Cela ne supprime pas le besoin de révision, mais cela donne aux réviseurs le même artefact au lieu de deux descriptions.
Que contient un fichier de conception d'interface utilisateur ouvert ?
La structure exacte dépend de l'outil, mais un fichier utile couvre les mêmes tâches :
- Disposition, y compris les points d'arrêt et la façon dont le composant est redistribué
- États d'interaction tels qu'inactif, survol, enfoncé, chargement, succès et erreur
- Mouvement, y compris les chronologies, la physique du printemps et les transitions entre les états
- Logique et conditions qui décident quel état est actif
- Entrées et événements pour que le code de l'application puisse piloter le composant et y réagir
- Liaisons de données pour les valeurs provenant de l'application au moment de l'exécution
Ce qui reste en dehors du fichier
Un fichier de composant ne représente pas l’intégralité de l’application. Le routage, l'authentification, la récupération de données, les autorisations, les analyses et le wrapper d'accessibilité autour d'un contrôle interactif restent dans votre base de code. La navigation sur la plateforme et les gestes du système restent généralement également spécifiques à la plateforme. Il est important d'être clair sur cette limite : un flux de travail à fichier unique est plus facile à adopter lorsqu'il gère le composant interactif et laisse les problèmes d'application à l'application.
Une équipe peut-elle examiner un seul dossier ?
Oui, si le format est ouvert et lisible. ExodeUI stocke un composant dans un fichier .exode JSON ouvert, afin que les modifications puissent être comparées, révisées et conservées dans le contrôle de version. Il s'agit d'un avantage pratique par rapport aux fichiers de conception binaires : un réviseur peut voir ce qui a changé dans le fichier et un outil de codage IA peut le lire sans décodeur propriétaire. L’ouverture ne répond pas à toutes les questions de gouvernance, mais elle rend possible la révision.
Comment ExodeUI utilise un fichier
Dans ExodeUI, un fichier .exode peut contenir la disposition, les points d'arrêt, les chronologies, les machines à états, la physique des ressorts, la logique, les entrées et les liaisons de données. Les packages d'exécution lisent le fichier dans React, Vue, Svelte, Angular, Solid, React Native, SwiftUI et Flutter. Votre code transmet les entrées et reçoit les événements au lieu de reformuler le mouvement. Le même fichier peut être ouvert dans le navigateur ou dans l'éditeur de bureau, et les outils de codage AI peuvent le modifier via le serveur MCP.
Quand un fichier est le mauvais choix
Un fichier ne convient pas à un travail qui n'est pas un composant interactif : une vidéo longue durée, des scènes 3D lourdes ou un tableau blanc de forme libre pour une idéation précoce. Cela ne convient pas non plus lorsqu'une équipe ne dispose d'aucun processus de révision et n'a besoin que d'un seul fichier pour appliquer elle-même les normes. Le format peut faciliter les bonnes pratiques. Cela ne peut pas remplacer la pratique.
Extrait d’implémentation en production
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()}
/>
);
}Principes clés à retenir
- Un flux de travail à fichier unique conserve la mise en page, les états, le mouvement, la logique et les entrées dans un seul document faisant autorité.
- Cela supprime l'étape de reconstruction du composant interactif, et non le besoin de révision.
- Les problèmes d'application tels que le routage, l'authentification et la récupération de données restent dans votre base de code
- Un fichier source JSON ouvert peut être comparé, versionné et lu par les outils d'IA
- ExodeUI lit le même fichier .exode via les environnements d'exécution sur les frameworks Web, mobiles et de bureau