Progetta una volta, esegui ovunque: un file dell'interfaccia utente su Web, iOS e Android
Ciò che serve veramente per progettare una volta ed eseguire un'interfaccia utente su Web, iOS e Android: layout e movimento condivisi, parti specifiche della piattaforma, test e dove si adatta ExodeUI.
Punto chiave
Progettare una volta, eseguire ovunque significa che un file sorgente descrive un componente dell'interfaccia utente e ciascuna piattaforma lo riproduce con un runtime, invece di ricostruire lo stesso movimento in React, SwiftUI e Flutter. Funziona quando layout, stati, movimento e input risiedono nel file condiviso e rimane onesto quando la navigazione, l'accessibilità e i gesti di sistema rimangono specifici della piattaforma. ExodeUI supporta questo modello con pacchetti runtime per React, Vue, Svelte, Angular, Solid, React Native, SwiftUI e Flutter.
Ciò che "progetta una volta, esegui ovunque" richiede effettivamente
Richiede più di un pulsante di esportazione. Il file condiviso deve descrivere come si presenta il componente in diverse dimensioni, come appare in ogni stato, come si sposta tra gli stati e come l'app lo guida con gli input. Ogni piattaforma necessita inoltre di un runtime in grado di riprodurre il file e collegare tali input a eventi reali. Se manca uno di questi pezzi, la promessa si trasforma in un altro passaggio di consegne.
File condivisi e ricostruzione per piattaforma
Il percorso tradizionale prevede di progettare una volta e ricostruire tre volte: web in CSS e JavaScript, iOS in SwiftUI e Android in Kotlin o Flutter. Ogni ricostruzione introduce piccole differenze nella tempistica, nella spaziatura e nella gestione dei gesti. Un percorso di file condiviso mantiene la definizione del componente in un unico posto e consente a ciascuna piattaforma di riprodurla. Il compromesso è che un runtime si trova tra il file e la piattaforma, quindi si rinuncia al controllo diretto sul rendering specifico della piattaforma.
Cosa dovrebbe rimanere specifico della piattaforma
Un componente condiviso non dovrebbe pretendere che ogni piattaforma sia uguale. I modelli di navigazione, i gesti indietro, le finestre di dialogo di sistema, le autorizzazioni e le API di accessibilità differiscono. Il file condiviso dovrebbe possedere la componente visiva interattiva; l'app host dovrebbe possedere la piattaforma Chrome e i controlli semantici attorno ad essa. Ad esempio, un pulsante animato condiviso può trovarsi all'interno di un elemento pulsante nativo che espone il ruolo e l'etichetta corretti.
Come funzionano i runtime
Un runtime legge il file, crea l'albero visivo e lo aggiorna quando cambiano gli input. Il codice dell'applicazione imposta input come premuto, disabilitato o in caricamento e ascolta eventi come conferma o eliminazione. Poiché la definizione visiva è costituita dai dati anziché dal codice scritto a mano per piattaforma, il runtime è ciò che rende portabile lo stesso file. Anche il runtime è una dipendenza, quindi misurane l'effetto sulla tua build invece di dare per scontato che sia gratuita.
Testare lo stesso file su ogni ambiente
Testa il file dove verrà eseguito, non solo nell'editor. Controlla il layout nelle dimensioni supportate più piccola e più grande, verifica ogni stato con contenuto reale e testa separatamente l'input touch, mouse e tastiera. Quindi controlla l'accessibilità: ordine dei focus, etichette, movimento ridotto e comportamento dello screen reader. Un file condiviso riduce la deriva visiva, ma non elimina la necessità di testare ciascuna piattaforma.
Dove si adatta ExodeUI
ExodeUI memorizza un componente in un file .exode aperto e fornisce pacchetti runtime per React, Vue, Svelte, Angular, Solid, React Native, SwiftUI e Flutter. Il file può includere layout e punti di interruzione, linee temporali, macchine a stati, fisica primaverile, input ed eventi. Lo stesso file può essere modificato nel browser o nell'editor desktop e gli strumenti di codifica AI possono lavorarci tramite il server MCP.
Quando non utilizzare un file condiviso
Un file condiviso non è adatto quando l'interfaccia dipende fortemente dalle API solo della piattaforma, quando è necessario il controllo a livello di pixel sul rendering nativo o quando il componente è principalmente un video o una scena 3D. Inoltre, non è adatto se la tua squadra non può testare ciascun obiettivo. In questi casi, il codice specifico della piattaforma è la scelta onesta e un file condiviso dovrebbe coprire solo le parti che ne traggono realmente beneficio.
Estratto di implementazione in produzione
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()}
/>
);
}Principi chiave da ricordare
- Progettare una volta ed eseguire ovunque richiede layout, stati, movimento e input condivisi, oltre a un runtime per piattaforma
- Le API di navigazione, autorizzazioni e accessibilità dovrebbero rimanere specifiche della piattaforma
- Un runtime è una dipendenza; misura il suo effetto sulla tua build
- Testa ogni target per layout, input, movimento e accessibilità
- ExodeUI fornisce runtime per React, Vue, Svelte, Angular, Solid, React Native, SwiftUI e Flutter