Interfejs View Migrate API to przełomowe rozwiązanie w tworzeniu stron internetowych. Niezależnie od tego, czy Twoja witryna ma jedną stronę czy wiele stron, ten zaawansowany interfejs API umożliwia płynne przełączanie się między widokami, dzięki czemu zachwycają one użytkowników, którzy widzą reklamy natywne. Obecnie ta funkcja jest dostępna w Chrome. Te same opcje wyświetlania dokumentów zostaną wkrótce udostępnione w Safari.
Coraz więcej osób zaczyna zapoznawać się z interfejsem View Przenoszenie API, dlatego nadszedł czas na obalenie niektórych błędnych przekonań.
Misja 1: Interfejs View Migrate API robi zrzuty ekranu
Gdy przenosisz widok, interfejs API tworzy zrzuty starego i nowego stanu treści. Będą one wtedy animowane zgodnie z opisem w sekcji „Jak działają te zmiany” 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. Pomyśl o nim jak o zastąpionym elemencie.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Dzięki aspektowi transmisji na żywo takie wersje demonstracyjne działają tak: film wygenerowany na podstawie nowego podsumowania jest odtwarzany w trakcie przejścia.
Funkcje logiczne i arkusze CSS użyte w tym celu są szczegółowo opisane w naszej dokumentacji.
Mit 2: Rejestrowanie więcej niż 1 elementu powoduje wyświetlanie wielu przejść
Jeśli 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 zrzutów, uruchamia się tylko jedno przejście z jednego widoku.
Obecnie w Chrome można uruchomić tylko 1 przejście widoku dla każdego dokumentu naraz. W tej prezentacji możesz szybko klikać szybko, aby rozpocząć nowy widok. Zauważysz, że trwające przejście przeskoczy do końca, gdy rozpocznie się nowy.
Mit 3: Nie można wdrożyć przejść z widokiem ze względu na obsługę przeglądarki
Wielu programistów obawia się, że nie mogą wdrożyć przejść z widokiem, ponieważ ta funkcja jest obsługiwana tylko w Chrome. Dobra wiadomość jest taka, że Safari pracuje nad tym rozwiązaniem i uwzględni je w nadchodzącej wersji Safari 18.
Nie pozwól jednak na to, by niedopracowana obsługa przeglądarek uniemożliwiła Ci wdrożenie przejść z widokiem. Przejścia widoku idealnie nadają się do progresywnego ulepszania. Metoda dodawania tej metodologii do kodu jest taka sama jak w oryginalnej dokumentacji.
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 widoku tego samego dokumentu, uzyskasz rozszerzoną, animowaną wersję. Jeśli jej nie widzisz, otrzymasz obecną wersję. Ponieważ coraz więcej przeglądarek obsługuje przełączanie widoku, tym większa liczba użytkowników będzie mieć dostęp do tej rozszerzonej wersji – a wszystko to automatycznie.
To samo dotyczy przejścia między widokami różnych dokumentów. Przeglądarki, które ich nie obsługują, podczas analizowania arkuszy stylów ignorują akceptację dla CSS.
To podejście zostało z powodzeniem wdrożone w branży e-commerce, jak opisaliśmy w tym studium przypadku.
Mit 4: Wyświetlanie przejść uszkodziło renderowanie przyrostowe
Istnieją roszczenia, które stwierdzają, że przejścia między wyświetleniami powodują przerwy w renderowaniu przyrostowym. To nieprawda: przejścia między wyświetleniami różnych dokumentów zostały określone w taki sposób, aby nie zakłócać tego podstawowego aspektu internetu.
Przeglądarki zaczynają renderować stronę, gdy mają „wystarczającą” ilość treści. Dzieje się tak w większości przeglądarek po wczytaniu wszystkich arkuszy stylów w elemencie <head>, analizie całego blokującego renderowanie kodu JavaScript w elemencie <head> i załadowaniu wystarczającej ilości znaczników. Przejścia widoku różnych dokumentów tego nie zmieniają: zawartość wymagana w przypadku pierwszego wyrenderowania treści jest niezmieniona. Po pierwszym wyrenderowaniu przeglądarka może renderować nowo otrzymane treści i stopniowo może je renderować.
Możesz blokować renderowanie do czasu, aż określony element znajdzie się w DOM. Jest to przydatne w sytuacjach, gdy chcesz mieć pewność, że elementy uwzględnione w przejściu widoku znajdują się na nowej stronie.
Aby to zrobić, użyj tego tagu linku:
<link rel="expect" blocking="render" href="#elementId">
Zastępuje to heurystykę przeglądarki używaną do określenia, kiedy wykonać pierwsze renderowanie: pierwsze renderowanie jest opóźnione do momentu pojawienia się określonego elementu w drzewie DOM.
Takie ręczne blokowanie ma wbudowane zabezpieczenia. Jeśli na przykład zamykający tag </html> jest widoczny, ale element blokujący nie jest widoczny, renderowanie nie będzie już blokowane. Możesz też dodać własną logikę czasu oczekiwania, która w każdej chwili usunie atrybut blokowania.
Widać, że blokowania renderowania należy używać z rozwagą. 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: Proces robienia zdjęć jest powolny lub kosztowny
Interfejs View Migrate API przygotowuje nowy widok i pobiera jego zrzuty, ale stary widok pozostaje widoczny dla użytkownika. W efekcie użytkownik widzi starą stronę trochę dłużej niż bez przełączania widoku. Opóźnienie to jest jednak niezauważalne, w rzeczywistości jedynie kilka klatek. Na przykład w Chrome wpływ funkcji 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 dotyczące zrzutów są pobierane bezpośrednio z kompozytora, więc w celu uzyskania danych zrzutu nie są wymagane dodatkowe czynności dotyczące układu lub ponownego renderowania.
Dodatkowy błędny przekaz: to interfejs View Migrates API.
Gdy mówimy o przejściach między widokami, użytkownicy często mają na myśli interfejs „View Migrates API”. To nie jest poprawna odpowiedź. Ten interfejs API nazywa się „View Migrate API” – zwróć uwagę na pojedynczą „Przejdź”.
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.
Kluczem do zapamiętania prawidłowej nazwy jest użycie (jednego) interfejsu View Migrate API do utworzenia (jednego lub więcej) przejść widoku.