View Transition API adalah game changer pengembangan web. Baik situs Anda terdiri dari satu halaman atau beberapa halaman, API yang canggih ini memungkinkan Anda membuat transisi yang lancar di antara tampilan, sehingga menghasilkan pengalaman seperti native yang memikat pengguna. Saat ini tersedia di Chrome, dengan transisi tampilan dokumen yang sama yang akan segera tersedia di Safari.
Dengan makin banyaknya orang yang mulai mengamati View Transition API, kini saatnya untuk menyanggah beberapa kesalahpahaman.
Kesalahpahaman 1: View Transition API mengambil screenshot
Saat menjalankan transisi tampilan, API akan mengambil snapshot dari status lama dan baru konten. Selanjutnya, snapshot ini akan dianimasikan, seperti yang dijelaskan di bagian "Cara kerja transisi ini" dalam dokumentasi.
Meskipun Anda dapat menggunakan istilah screenshot untuk snapshot lama, snapshot baru bukanlah screenshot, melainkan representasi langsung dari node. Anggap saja sebagai elemen yang diganti.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
Berkat aspek live ini, demo seperti ini dapat berfungsi: video–yang bersumber dari snapshot baru–terus diputar saat transisi tampilan terjadi.
Logika dan CSS yang digunakan untuk ini dijelaskan secara mendetail dalam dokumentasi kami.
Kesalahpahaman 2: Merekam lebih dari satu elemen akan menyebabkan beberapa transisi tampilan berjalan
Saat Anda mengambil beberapa elemen, proses pengambilan snapshot akan mengambil semua status lama dan baru. Saat Anda mengambil .box selain elemen :root, Anda akan mendapatkan pohon semu ini:
::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)
Meskipun hierarki ini berisi beberapa pasangan snapshot, hanya satu transisi tampilan yang akan dijalankan.
Saat ini, Chrome dibatasi untuk menjalankan satu transisi tampilan per dokumen secara bersamaan. Coba klik dengan cepat dalam demo ini untuk memulai transisi tampilan baru. Anda akan melihat transisi yang sedang berlangsung dilewati hingga akhir saat transisi baru dimulai.
Kesalahpahaman 3: Anda tidak dapat menerapkan transisi tampilan karena dukungan browser
Banyak developer khawatir mereka tidak dapat menerapkan transisi tampilan karena hanya didukung di Chrome. Kabar baiknya adalah Safari sedang mengerjakannya dan akan menyertakannya dalam rilis Safari 18 mendatang.
Namun, jangan biarkan dukungan browser yang tidak konsisten menghalangi Anda menerapkan transisi tampilan sekarang. Transisi tampilan adalah materi yang tepat untuk progressive enhancement. Dokumentasi asli membagikan metode untuk menambahkan metodologi ini ke kode Anda.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
Jika browser Anda mendukung transisi tampilan dokumen yang sama, Anda akan mendapatkan versi animasi yang diperkaya. Jika tidak, Anda akan mendapatkan pengalaman saat ini. Seiring waktu, karena semakin banyak browser yang mendukung transisi tampilan, semakin banyak pengguna yang akan merasakan versi yang diperkaya ini, semuanya secara otomatis.
Hal yang sama berlaku untuk transisi tampilan lintas dokumen. Browser yang tidak mendukungnya akan mengabaikan keikutsertaan CSS saat mengurai stylesheet.
Pendekatan ini berhasil diterapkan di e-commerce, seperti yang dijelaskan dalam studi kasus ini
Kesalahpahaman 4: Transisi tampilan merusak rendering inkremental
Ada klaim bahwa transisi tampilan merusak rendering inkremental. Hal ini tidak benar: Transisi tampilan lintas dokumen ditentukan agar tidak merusak aspek fundamental web ini.
Browser mulai merender halaman saat memiliki konten yang "cukup". Langkah ini–di sebagian besar browser–setelah memuat semua stylesheet di <head>, menguraikan semua JavaScript yang memblokir perenderan di <head>, dan memuat markup yang memadai. Transisi tampilan lintas dokumen tidak mengubah hal ini: konten yang diperlukan untuk First Contentful Paint tidak diubah. Setelah rendering pertama ini, browser dapat–dan akan–merender konten yang baru diterima secara bertahap.
Anda dapat memilih untuk memblokir rendering hingga elemen tertentu ada di DOM. Hal ini praktis jika Anda ingin memastikan bahwa elemen yang berpartisipasi dalam transisi tampilan ada di halaman baru.
Untuk melakukannya, gunakan tag link ini:
<link rel="expect" blocking="render" href="#elementId">
Hal ini akan mengganti heuristik browser yang digunakan untuk memutuskan kapan harus melakukan rendering pertama: rendering pertama akan tertunda hingga elemen yang ditentukan ada di hierarki DOM.
Pemblokiran manual ini memiliki beberapa pengamanan bawaan. Misalnya, jika tag </html> penutup terlihat, tetapi elemen pemblokiran tidak terlihat, rendering tidak akan lagi diblokir. Selain itu, Anda dapat menambahkan logika waktu tunggu Anda sendiri yang menghapus atribut pemblokiran kapan saja.
Jelas bahwa pemblokiran render harus digunakan dengan hati-hati. Dampak dari rendering pemblokiran perlu dievaluasi berdasarkan kasus per kasus. Secara default, hindari penggunaan blocking=render kecuali jika Anda dapat secara aktif mengukur dan menilai dampaknya terhadap pengguna, dengan mengukur dampaknya terhadap metrik performa.
Kesalahpahaman 5: Proses pembuatan snapshot lambat atau mahal
Saat View Transition API menyiapkan tampilan baru dan mendapatkan snapshot-nya, tampilan lama tetap terlihat oleh pengguna. Oleh karena itu, pengguna dapat melihat halaman lama sedikit lebih lama daripada tanpa transisi tampilan. Namun, penundaan ini dapat diabaikan, karena pada kenyataannya hanya beberapa frame. Di Chrome, dampak pageswap misalnya adalah maksimal dua frame yang tidak berlaku: Satu untuk mengeksekusi logika ditambah satu frame tambahan untuk memastikan snapshot telah dikomposisi dan di-cache.
Selain itu, data untuk snapshot diambil langsung dari kompositor, sehingga tidak ada langkah tata letak atau pengecatan ulang tambahan yang perlu dilakukan untuk mendapatkan data snapshot.
Kesalahpahaman Bonus: Ini adalah View Transitions API
Saat membahas transisi tampilan, orang sering merujuk ke "View Transitions API". Ini salah. API ini disebut "View Transition API"–perhatikan "Transition" tunggalnya.
Kesalahpahaman tersebut berasal dari beberapa artikel, termasuk dokumen kami sendiri tentang DCC, yang menggunakan istilah yang salah.
Trik untuk mengingat nama yang benar adalah menggunakan (satu) View Transition API untuk membuat (satu atau beberapa) transisi tampilan.