Interfejs View Migrate API to przełomowe rozwiązanie w zakresie tworzenia stron internetowych. Niezależnie od tego, czy Twoja witryna składa się z jednej strony czy z wielu stron, to potężne API umożliwia tworzenie płynnych przejść między widokami, co zapewnia użytkownikom wygodę i zachęca ich do korzystania z witryny. Obecnie ta funkcja jest dostępna w Chrome, a wkrótce będzie też dostępna w Safari.
Coraz więcej osób zaczyna korzystać z interfejsu View Transition API, dlatego warto obalić kilka mitów.
Błąd 1. Interfejs View Transition API wykonuje zrzuty ekranu
Podczas przełączania widoku interfejs API wykonuje zrzuty ekranu starego i nowego stanu treści. Następnie te migawki są animowane, zgodnie z opisem w sekcji „Jak działają te przejścia” w dokumentacji.
Chociaż w odniesieniu do starego zrzutu można użyć terminu, nowy zrzut nie jest zrzutem ekranu, ale w rzeczywistości reprezentacją węzła. Możesz go traktować jako element zastąpiony.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Dzięki temu demo działają: film pochodzący z nowego migawka będzie odtwarzany podczas przejścia.
Szczegółowe informacje o zastosowanych w tym celu regułach i szablonach CSS znajdziesz w naszej dokumentacji.
Mit 2: Rejestrowanie więcej niż 1 elementu powoduje wyświetlanie wielu przejść
Gdy rejestrujesz wiele elementów, proces tworzenia migawki obejmuje wszystkie stare i nowe stany. Gdy oprócz elementu :root przechwycisz obiekt .box, otrzymasz to pseudodrzewo:
::view-transition
└─ ::view-transition-group(root)
| └─ ::view-transition-image-pair(root)
| ├─ ::view-transition-old(root)
| └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
└─ ::view-transition-image-pair(box)
├─ ::view-transition-old(box)
└─ ::view-transition-new(box)
Chociaż to drzewo zawiera wiele par snapshotów, tylko jeden widok przejścia jest uruchamiany.
Obecnie w Chrome można uruchomić tylko 1 przejście widoku dla każdego dokumentu naraz. Spróbuj szybko klikać w tym pokazie demonstracyjnym, aby rozpocząć nowe przejście między widokami. Gdy rozpocznie się nowe przejście, bieżące przeskoczy do końca.
Błąd 3. Nie można stosować przejść między widokami ze względu na obsługę w przeglądarkach
Wielu deweloperów obawia się, że nie może wdrożyć przejść między widokami, ponieważ są one obsługiwane tylko w Chrome. Dobra wiadomość jest taka, że zespół Safari pracuje nad tym problemem i uwzględni go w przyszłej wersji Safari 18.
Nie pozwól jednak ograniczonej obsłudze przeglądarek przeszkodzić Ci w wdrożeniu przejść między widokami. Przejścia między widokami to idealny materiał do ulepszania stopniowego. W pierwotnej dokumentacji znajdziesz sposób na dodanie tej metody do kodu.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Jeśli Twoja przeglądarka obsługuje przejścia w tym samym dokumencie, wyświetli się wzbogacona, animowana wersja. Jeśli jej nie widzisz, otrzymasz obecną wersję. Z czasem, gdy coraz więcej przeglądarek będzie obsługiwać przejścia między widokami, coraz więcej użytkowników będzie automatycznie korzystać z ulepszonej wersji.
To samo dotyczy przejścia między widokami różnych dokumentów. Przeglądarki, które ich nie obsługują, ignorują zgodę na korzystanie z kodu CSS podczas analizowania arkuszy stylów.
To podejście zostało z powodzeniem wdrożone w branży e-commerce, jak opisaliśmy w tym studium przypadku.
Mit 4. Przechodzenie między widokami zakłóca renderowanie przyrostowe
Istnieją zarzuty, że przejścia między widokami powodują przerwanie renderowania cząstkowego. To nieprawda: przejścia między widokami dokumentów zostały określone tak, aby nie zakłócać tego podstawowego aspektu internetu.
Przeglądarki zaczynają renderować stronę, gdy mają „wystarczającą” ilość treści. W większości przeglądarek oznacza to, że po załadowaniu wszystkich arkuszy stylów w elementach <head>, przeanalizowaniu wszystkich elementów JavaScript blokujących renderowanie w elementach <head> oraz załadowaniu wystarczającej ilości znaczników. Przejścia między widokami dokumentów nie zmieniają tego: zawartość wymagana do pierwszego wyrenderowania elementu znaczącego pozostaje niezmieniona. Po pierwszym wyrenderowaniu przeglądarka może – i stopniowo – renderować nowo otrzymane treści.
Możesz zablokować renderowanie, dopóki w DOM nie pojawi się określony element. Jest to przydatne, gdy chcesz mieć pewność, że elementy biorące udział w przechodzeniu między widokami są obecne na nowej stronie.
Aby to zrobić, użyj tego tagu linku:
<link rel="expect" blocking="render" href="#elementId">
Zastępuje to heurystyki przeglądarki używane do określania, kiedy ma nastąpić pierwsze wyrenderowanie: pierwsze wyrenderowanie jest opóźnione, dopóki określony element nie pojawi się w drzewie DOM.
Blokowanie ręczne ma wbudowane środki ochrony. Jeśli na przykład tag zamykający </html> jest widoczny, ale element blokujący nie jest widoczny, renderowanie nie będzie już blokowane. Możesz też dodać własną logikę limitu czasu, która w dowolnym momencie usuwa atrybut blokowania.
Należy ostrożnie używać układu dynamicznego. Wpływ renderowania blokującego trzeba ocenić indywidualnie. Domyślnie unikaj używania usługi blocking=render, chyba że możesz aktywnie zmierzyć i zmierzyć jej wpływ na użytkowników, mierząc wpływ tej zmiany na dane o skuteczności.
Mit 5. Tworzenie migawek jest powolne lub drogie
Podczas gdy interfejs View Transition API przygotowuje nowy widok i pobiera jego migawki, stary widok pozostaje widoczny dla użytkownika. W efekcie użytkownik widzi starą stronę trochę dłużej niż bez przełączania widoku. To opóźnienie jest jednak nieistotne, bo w istocie to tylko kilka klatek. Na przykład w Chrome wpływ reguły pageswap to maksymalnie 2 nieaktualne ramki: jedna do wykonania funkcji logicznej oraz 1 dodatkowa ramka, która ma zapewnić skomponowanie i zapisanie zrzutów w pamięci podręcznej.
Ponadto dane do zrzutów są pobierane bezpośrednio z kompozytora, więc nie trzeba wykonywać dodatkowych czynności związanych z układem ani ponownym rysowaniem, aby uzyskać dane zrzutu.
Dodatkowy mit: to interfejs View Transitions API
W przypadku przejść między widokami często mówi się o „View Transitions API”. To nie jest poprawna odpowiedź. Ten interfejs API nazywa się „View Migrate API” – zwróć uwagę na liczbę pojedynczą „przejść”.
Nieprawdziwe przekonania wynika z niektórych artykułów, w tym w pewnym momencie z naszych własnych dokumentów dotyczących DCC, w których użyto niewłaściwego terminu.
Aby zapamiętać poprawną nazwę, użyj (jednego) interfejsu View Transition API, aby utworzyć (jeden lub więcej) widok przejścia.