Interfejs View Transition API to przełom w rozwoju stron internetowych. Niezależnie od tego, czy Twoja witryna składa się z jednej strony, czy z wielu, 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, więc czas obalić kilka mitów.
Powszechny poglą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 przypadku starego zrzutu ekranu można użyć terminu „zrzut ekranu”, nowy zrzut ekranu nie jest zrzutem ekranu, ale rzeczywistym odwzorowaniem 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.
Błędne przekonanie 2. Wykrywanie więcej niż jednego elementu powoduje uruchomienie wielu przejść między widokami
Gdy uchwycisz wiele elementów, proces tworzenia migawek uchwyci wszystkie stare i nowe stany. Gdy obok elementu :root
uchwycisz element .box
, otrzymasz 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 Chrome umożliwia jednoczesne wyświetlanie tylko jednego widoku na dokument. 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.
Mit 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 nie, zobaczysz 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 przechodów między widokami 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 e-commerce, jak opisano w tym opracowaniu.
Mit 4. Przechodzenie między widokami zakłóca renderowanie przyrostowe
Istnieją zarzuty, że przejścia między widokami zakłócają renderowanie przyrostowe. 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 renderowaniu przeglądarka może i będzie 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 wykonać pierwsze wyrenderowanie: pierwsze wyrenderowanie jest opóźnione, dopóki określony element nie pojawi się w drzewie DOM.
To ręczne zablokowanie ma wbudowane zabezpieczenia. 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 blokowania renderowania należy oceniać indywidualnie w każdej sytuacji. Domyślnie unikaj używania blocking=render
, chyba że możesz aktywnie mierzyć i ocenić wpływ tej funkcji na użytkowników, mierząc wpływ na dane o wydajnoś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. Dzięki temu użytkownik widzi starą stronę przez nieco dłuższy czas niż bez przejść między widokami. To opóźnienie jest jednak nieistotne, bo w istocie to tylko kilka klatek. W Chrome wpływ funkcji pageswap
to maksymalnie 2 nieaktualne klatki: jedna do wykonania logiki oraz dodatkowa klatka, aby zapewnić złożenie i zapisanie w pamięci podręcznej zrzutów ekranu.
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ź. Interfejs API nosi nazwę „View Transition API” (zwróć uwagę na pojedyncze słowo „Transition”).
Pomyłka wynika z nieprawidłowego użycia terminu w niektórych artykułach, w tym w naszych dokumentach na temat DCC.
Aby zapamiętać poprawną nazwę, użyj (jednego) interfejsu View Transition API, aby utworzyć (co najmniej 1) przejście widoku.