L'API View Transizione è stata rivoluzionaria per lo sviluppo web. Che il tuo sito web sia di una o più pagine, questa potente API ti consente di creare transizioni fluide tra le visualizzazioni, dando vita a esperienze simili a quelle native che attirano gli utenti. Attualmente disponibile in Chrome, con le transizioni di visualizzazione degli stessi documenti presto disponibili in Safari.
Con sempre più persone che iniziano a esaminare l'API View Transizione, è il momento di sfatare alcuni equivoci.
Idea errata 1: l'API View Transizione acquisisce screenshot
Durante l'esecuzione di una transizione di visualizzazione, l'API acquisisce snapshot dello stato vecchio e nuovo dei contenuti. Queste istantanee vengono quindi animate, come descritto in dettaglio nella sezione "Come funzionano queste transizioni" della documentazione.
Puoi usare il termine screenshot per la vecchia snapshot, ma la nuova istantanea non è uno screenshot, ma una rappresentazione in tempo reale del nodo. È una sorta di elemento sostituito.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Grazie a questo aspetto dal vivo, demo come questa funzionano: il video, proveniente dalla nuova istantanea, continua a essere riprodotto mentre è in corso la transizione della visualizzazione.
La logica e il CSS utilizzati a tale scopo sono dettagliati nella nostra documentazione.
Idea errata 2: l'acquisizione di più elementi comporta l'esecuzione di più transizioni di visualizzazione
Quando acquisisci più elementi, il processo di creazione di snapshot acquisisce tutti gli stati vecchi e nuovi. Quando acquisisci un elemento .box oltre all'elemento :root, ottieni questo pseudo albero:
::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)
Anche se questo albero contiene più coppie di snapshot, viene eseguita una singola transizione di visualizzazione.
Attualmente, Chrome è limitato a eseguire una sola transizione di visualizzazione per documento alla volta. Prova a fare clic rapidamente in questa demo per avviare una nuova transizione di visualizzazione. Noterai che la transizione in corso salta alla fine, quando ne inizia una nuova.
Idea errata 3: non è possibile implementare le transizioni di visualizzazione a causa del supporto del browser
Molti sviluppatori temono di non poter implementare le transizioni di visualizzazione perché questa funzionalità è supportata solo su Chrome. Una buona notizia è che Safari ci sta lavorando e lo includerà nell'imminente release di Safari 18.
Tuttavia, fai in modo che il supporto instabile del browser non ti impedisca di implementare oggi stesso le transizioni di visualizzazione. Le transizioni di tipo Vista sono il materiale perfetto per il miglioramento progressivo. La documentazione originale condivide un metodo per aggiungere questa metodologia al codice.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Se il tuo browser supporta le transizioni di visualizzazione nello stesso documento, ottieni la versione arricchita e animata. Se il browser non funziona, significa che viene visualizzata l'esperienza corrente. Con il passare del tempo, poiché sempre più browser supportano le transizioni di visualizzazione, più utenti potranno sperimentare questa versione arricchita, il tutto automaticamente.
Lo stesso vale per le transizioni di visualizzazione tra documenti. I browser che non li supportano ignoreranno l'attivazione CSS durante l'analisi dei fogli di stile.
Questo approccio è stato implementato con successo nell'e-commerce, come descritto in dettaglio in questo case study.
Idea errata 4: le transizioni di visualizzazione interrompono il rendering incrementale
Esistono rivendicazioni secondo le quali le transizioni della visualizzazione interrompono il rendering incrementale. Questo non è vero: le transizioni di visualizzazione tra documenti sono state specificate in modo da non interrompere questo aspetto fondamentale del web.
I browser iniziano a eseguire il rendering di una pagina quando hanno contenuti "sufficienti". Nella maggior parte dei browser, questo avviene dopo il caricamento di tutti i fogli di stile in <head>, l'analisi di tutto il codice JavaScript che blocca la visualizzazione in <head> e il caricamento di markup sufficiente. Le transizioni di visualizzazione tra documenti non cambiano questa situazione: i contenuti richiesti per la funzionalità First Contentful Paint rimangono invariati. Dopo questo primo rendering, il browser può eseguire il rendering dei nuovi contenuti ricevuti e lo farà in modo incrementale.
Puoi scegliere di bloccare il rendering finché non è presente un determinato elemento nel DOM. Questa operazione è utile se vuoi assicurarti che gli elementi che partecipano alla transizione della visualizzazione siano presenti nella nuova pagina.
A questo scopo, utilizza questo tag link:
<link rel="expect" blocking="render" href="#elementId">
Questa operazione sostituisce l'euristica del browser utilizzata per decidere quando eseguire il primo rendering: il primo viene ritardato fino a quando l'elemento specificato non è presente nella struttura DOM.
Questo blocco manuale presenta alcune misure di salvaguardia integrate. Ad esempio, quando viene visualizzato il tag </html> di chiusura, ma l'elemento di blocco no, il rendering non sarà più bloccato. Inoltre, puoi aggiungere una logica di timeout personalizzata che rimuove l'attributo di blocco in qualsiasi momento.
È evidente che il blocco del rendering deve essere utilizzato con cautela. L'impatto del blocco del rendering deve essere valutato caso per caso. Per impostazione predefinita, evita di utilizzare blocking=render, a meno che tu non possa misurare e valutare attivamente l'impatto che ha sui tuoi utenti misurando l'impatto sulle metriche sul rendimento.
Idea errata 5: il processo di creazione di snapshot è lento o costoso
Mentre l'API View Transizione prepara la nuova vista e acquisisce le istantanee, la vista precedente rimane visibile all'utente. Per questo motivo, l'utente vedrà la vecchia pagina un po' più a lungo rispetto a quando non avrà transizioni di visualizzazione. Tuttavia, questo ritardo è trascurabile, in realtà solo pochi frame. In Chrome, ad esempio, l'impatto di pageswap è pari al massimo a due frame inattivi: uno per eseguire la logica e un frame aggiuntivo per garantire che gli snapshot siano stati composti e memorizzati nella cache.
Inoltre, i dati per gli snapshot vengono recuperati direttamente dal compositore, pertanto non sono necessari passaggi aggiuntivi di layout o ricolorazione per ottenere i dati degli snapshot.
Suggerimento sbagliato: è l'API View Transiziones
Quando si parla di transizioni di visualizzazione, spesso si fa riferimento all'API "View Transitions". Risposta errata. L'API è denominata "API View Transizione" (nota: "Transizione".
Questo equivoco deriva da alcuni articoli, tra cui a un certo punto i nostri documenti su DCC, che utilizzano il termine sbagliato.
Il trucco per ricordare il nome corretto è utilizzare la (una) API View Transizione per creare (una o più) transizioni di visualizzazione.