Zaprojektuj raz, uruchamiaj wszędzie: jeden plik interfejsu użytkownika w Internecie, iOS i Androidzie
Czego naprawdę potrzeba, aby jednorazowo zaprojektować i uruchomić interfejs użytkownika w Internecie, iOS i Androidzie: wspólny układ i ruch, części specyficzne dla platformy, testowanie i miejsce, w którym pasuje ExodeUI.
Rdzeń na wynos
Projektuj raz, uruchamiaj wszędzie oznacza, że jeden plik źródłowy opisuje komponent interfejsu użytkownika i każda platforma odtwarza go w środowisku wykonawczym, zamiast odbudowywać ten sam ruch w React, SwiftUI i Flutter. Działa, gdy układ, stany, ruch i dane wejściowe znajdują się w udostępnionym pliku, i pozostaje uczciwy, gdy nawigacja, dostępność i gesty systemowe pozostają specyficzne dla platformy. ExodeUI obsługuje ten model z pakietami wykonawczymi dla React, Vue, Svelte, Angular, Solid, React Native, SwiftUI i Flutter.
Czego właściwie wymaga zasada „zaprojektuj raz, uruchamiaj wszędzie”.
Wymaga czegoś więcej niż przycisku eksportu. Udostępniony plik musi opisywać układ komponentu w różnych rozmiarach, jak wygląda w każdym stanie, jak przemieszcza się między stanami oraz w jaki sposób aplikacja steruje nim za pomocą danych wejściowych. Każda platforma potrzebuje także środowiska wykonawczego, które może odtworzyć plik i połączyć te dane wejściowe z rzeczywistymi zdarzeniami. Jeśli brakuje któregokolwiek z tych elementów, obietnica zamienia się w kolejne przekazanie.
Udostępniony plik a przebudowa na platformę
Tradycyjną drogą jest zaprojektowanie raz i przebudowa trzykrotnie: internet w CSS i JavaScript, iOS w SwiftUI i Android w Kotlin lub Flutter. Każda przebudowa wprowadza niewielkie różnice w czasie, odstępach i obsłudze gestów. Udostępniona trasa pliku przechowuje definicję komponentu w jednym miejscu i umożliwia odtwarzanie jej na każdej platformie. Kompromis polega na tym, że środowisko wykonawcze znajduje się pomiędzy plikiem a platformą, więc rezygnujesz z bezpośredniej kontroli nad renderowaniem specyficznym dla platformy.
Co powinno pozostać zależne od platformy
Komponent współdzielony nie powinien udawać, że każda platforma jest taka sama. Wzorce nawigacji, gesty cofania, okna dialogowe systemu, uprawnienia i interfejsy API ułatwień dostępu różnią się. Udostępniony plik powinien zawierać interaktywny komponent wizualny; aplikacja hosta powinna posiadać platformę Chrome i semantyczne elementy sterujące wokół niej. Na przykład udostępniony animowany przycisk może znajdować się wewnątrz natywnego elementu przycisku, który eksponuje odpowiednią rolę i etykietę.
Jak działają środowiska wykonawcze
Środowisko wykonawcze odczytuje plik, buduje drzewo wizualne i aktualizuje je w miarę zmiany danych wejściowych. Twój kod aplikacji ustawia dane wejściowe, takie jak naciśnięcie, wyłączenie lub ładowanie, i nasłuchuje zdarzeń, takich jak potwierdzenie lub odrzucenie. Ponieważ definicja wizualna to dane, a nie odręczny kod na platformę, środowisko wykonawcze sprawia, że ten sam plik jest przenośny. Środowisko wykonawcze jest również zależnością, więc zmierz jego wpływ na własną kompilację, zamiast zakładać, że jest bezpłatna.
Testowanie tego samego pliku w każdym środowisku
Przetestuj plik tam, gdzie będzie działał, a nie tylko w edytorze. Sprawdź układ w najmniejszych i największych obsługiwanych rozmiarach, zweryfikuj każdy stan z rzeczywistą zawartością i przetestuj osobno dotyk, mysz i klawiaturę. Następnie sprawdź dostępność: kolejność fokusów, etykiety, ograniczenie ruchu i zachowanie czytnika ekranu. Udostępniony plik zmniejsza dryf wizualny, ale nie eliminuje konieczności testowania każdej platformy.
Gdzie pasuje ExodeUI
ExodeUI przechowuje komponent w otwartym pliku .exode i udostępnia pakiety wykonawcze dla React, Vue, Svelte, Angular, Solid, React Native, SwiftUI i Flutter. Plik może zawierać układ i punkty przerwania, osie czasu, maszyny stanowe, fizykę sprężyn, dane wejściowe i zdarzenia. Ten sam plik można edytować w przeglądarce lub edytorze komputerowym, a narzędzia kodujące AI mogą na nim pracować za pośrednictwem serwera MCP.
Kiedy nie używać jednego udostępnionego pliku
Udostępniony plik nie jest dobrym rozwiązaniem, gdy interfejs w dużym stopniu zależy od interfejsów API dostępnych wyłącznie na platformie, gdy wymagana jest kontrola na poziomie pikseli nad renderowaniem natywnym lub gdy komponent składa się głównie z wideo lub sceny 3D. Jest to również kiepskie rozwiązanie, jeśli Twój zespół nie może przetestować każdego celu. W takich przypadkach kod specyficzny dla platformy jest uczciwym wyborem, a udostępniony plik powinien obejmować tylko te części, które rzeczywiście z niego korzystają.
Fragment wdrożenia produkcyjnego
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()}
/>
);
}Klucz Principles do zapamiętania
- Projektuj raz i uruchamiaj wszędzie wymaga wspólnego układu, stanów, ruchu i danych wejściowych, a także środowiska wykonawczego na platformę
- Interfejsy API nawigacji, uprawnień i ułatwień dostępu powinny pozostać specyficzne dla platformy
- Środowisko wykonawcze jest zależnością; zmierz jego wpływ na twoją kompilację
- Przetestuj każdy cel pod kątem układu, danych wejściowych, ruchu i dostępności
- ExodeUI zapewnia czasy działania dla React, Vue, Svelte, Angular, Solid, React Native, SwiftUI i Flutter