Gesaan dan skop
Satu produk mahukan kesan View Transition API untuk perubahan laluan SPA dan pembukaan paparan butiran imej. Terangkan pelaksanaannya dan cara anda mengendalikan pelayar lama, prefers-reduced-motion, data tak segerak, fokus, kegagalan animasi dan sandaran prestasi.
Ini menguji sempadan API dan peningkatan progresif, bukannya animasi demo semata-mata. MDN mendefinisikan document.startViewTransition() sebagai titik masuk kemas kini dokumen yang sama dan menyatakan bahawa peralihan diteruskan selepas panggilan balik selesai; peralihan rentas dokumen juga memerlukan asal yang sama (same origin) dan @view-transition CSS. Animasi mesti menyokong perubahan keadaan dan tidak sekali-kali menyekat kebolehgunaan.
Perkara yang sedang diuji oleh penemu duga
Pertama, bolehkah anda membezakan antara peralihan SPA dokumen yang sama, skop elemen dan rentas dokumen? Kedua, bolehkah anda mengendalikan API yang tidak disokong, panggilan balik yang ditolak, pergerakan yang dikurangkan (reduced motion) dan keluar daripada halaman? Ketiga, bolehkah anda mengekalkan fokus, DOM semantik, penatalan dan interaksi sebenar dan bukannya menyembunyikannya di sebalik animasi snapshot?
Soalan untuk dijelaskan sebelum menjawab
- Apakah sempadan yang sedang beralih? Kemas kini DOM dokumen yang sama, satu elemen, atau navigasi antara dokumen?
- Adakah kemas kini menyertakan data tak segerak? Perkara yang mesti disediakan terlebih dahulu, dan berapakah masa menunggu maksimum?
- Apakah pengalaman pelayar lama yang boleh diterima? Kemas kini keadaan yang sama mesti berfungsi tanpa animasi.
- Pengguna manakah yang mengurangkan atau melumpuhkan pergerakan? Bagaimanakah
prefers-reduced-motiondan tetapan aplikasi digabungkan? - Bagaimanakah keadaan halaman dipulihkan? Fokus, tatal, input borang dan navigasi ke belakang?
- Berapakah belanjawan prestasi? Skop snapshot, tempoh masa, peranti berspesifikasi rendah dan peralihan serentak?
Rangka kerja jawapan 30 saat
"Saya akan mengasingkan kemas kini keadaan daripada animasi: apabila disokong, balut kemas kini DOM segerak dalam startViewTransition; jika tidak, jalankan kemas kini yang sama secara terus. Sediakan data tak segerak dalam laluan atau komponen, pastikan panggilan balik tertumpu pada melakukan keadaan yang telah siap, dan perhatikan ready, finished dan skipTransition. Gunakan named views untuk mengehadkan skop, memendekkan atau melumpuhkan pergerakan di bawah prefers-reduced-motion, memulihkan fokus dan tatal, serta memastikan kegagalan animasi tidak menghalang interaksi. Sahkan tugas yang panjang, bilangan snapshot, masa penyiapan dan kadar sandaran pada peranti berspesifikasi rendah."
Perbincangan mendalam langkah demi langkah
Langkah 1: Tentukan kemas kini keadaan dan matlamat animasi
Namakan dua keadaan yang disambungkan oleh animasi, seperti kad senarai ke halaman butiran atau hasil yang ditapis ke senarai baharu, dan bukannya memudarkan keseluruhan halaman tanpa perbezaan. Kemas kini mestilah betul tanpa animasi; animasi ialah lapisan peningkatan. Tentukan nama peralihan yang dibenarkan dan tingkah laku sandaran untuk setiap jenis navigasi.
Langkah 2: Kesan sokongan dan kekalkan sandaran segerak
Semak document.startViewTransition sebelum memanggilnya. Pelayar yang tidak disokong melaksanakan fungsi kemas kini yang sama secara terus; jangan gandakan logik perniagaan. Sokongan pelayar baharu tidak merangkumi setiap peranti lama, jadi kekalkan laluan sandaran seperti yang diperlukan oleh panduan keserasian MDN.
Langkah 3: Batasi panggilan balik dan data tak segerak
updateCallback berjalan selepas snapshot paparan lama; Promise yang dikembalikan mesti dipenuhi sebelum bingkai seterusnya. Ambil data sebelum bermula jika boleh. Jika panggilan balik mesti menunggu, tetapkan had masa tamat (timeout) dan benarkan peralihan dilangkau. Panggilan balik yang ditolak mengikut pengendalian ralat perniagaan biasa dan tidak boleh mendedahkan halaman yang dikemas kini separuh jalan.
const update = () => renderState(nextState);
if (!document.startViewTransition || reduceMotion) {
update();
} else {
const transition = document.startViewTransition(update);
transition.finished.catch(() => {
// Animation failure does not roll back the completed state update.
});
}Langkah 4: Hadkan snapshot dengan named views
Berikan view-transition-name yang unik hanya kepada elemen yang benar-benar berkongsi kedudukan. Komponen senarai yang berulang tidak boleh berkongsi satu nama tanpa kekaburan. Untuk senarai dinamik, kosongkan nama lama sebelum mengemas kini dan tetapkan nama unik yang stabil selepas itu.
Langkah 5: Laksanakan pergerakan yang dikurangkan dan tingkah laku yang boleh diakses
Dengar pada prefers-reduced-motion: reduce, tetapkan tempoh kepada sifar atau hampir sifar, dan kekalkan perubahan keadaan. Jangan sembunyikan fokus papan kekunci atau menyampaikan keputusan hanya melalui warna. Selepas kemas kini, alihkan fokus ke tajuk paparan baharu atau yang setara. web.dev memberi amaran bahawa animasi peralihan paparan skrin penuh boleh menimbulkan ketidakselesaan kepada individu yang mengalami gangguan vestibular.
Langkah 6: Kendalikan perbezaan SPA, elemen dan rentas dokumen
SPA membalut kemas kini DOM dengan document.startViewTransition; peralihan berskop elemen mempengaruhi elemen pemanggil dan keturunannya; navigasi rentas dokumen memerlukan asal yang sama dan penglibatan (opt-in) @view-transition dalam kedua-dua dokumen. Jangan menganggap bahawa panggilan balik JS dokumen yang sama wujud merentasi kitaran hayat dokumen.
Langkah 7: Reka bentuk laluan langkau, keserentakan dan kegagalan
Untuk klik yang pantas, batalkan atau gabungkan navigasi lapuk supaya peralihan tidak bersaing untuk nod yang sama. Gunakan skipTransition() atau had masa tamat untuk menamatkan animasi yang tersekat. Sebaik sahaja keadaan perniagaan dikemas kini, kegagalan visual tidak boleh menyebabkan penyerahan pendua, permintaan pendua atau pengunduran (rollback) yang salah.
Langkah 8: Sahkan prestasi dan pengalaman pengguna sebenar
Pantau masa mula hingga tamat, nisbah langkau, tugasan panjang, CLS, kelewatan input dan ralat peranti berspesifikasi rendah. Uji senarai besar, rangkaian perlahan, kerja tak segerak yang ditolak, navigasi ke belakang yang pantas, pembaca skrin dan pergerakan yang dikurangkan. Sahkan snapshot dan animasi tidak pernah membuatkan interaksi sebenar menunggu lebih lama.
Pertukaran (Trade-offs) dan sempadan
Pertukaran 1: Peralihan halaman penuh atau tempatan
Peralihan halaman penuh adalah lebih mudah tetapi memerlukan lebih banyak snapshot dan boleh mengganggu fokus serta tatalan. Peralihan tempatan memerlukan nama yang stabil dan sempadan komponen yang tepat, menjadikannya lebih baik untuk interaksi yang kerap dan halaman yang besar.
Pertukaran 2: Tunggu data atau beralih serta-merta
Menunggu dapat mengelakkan ketidakpadanan kandungan lama/baharu tetapi meningkatkan masa tindak balas. Utamakan prapengambilan (prefetching); jika tidak, tunjukkan keadaan pemuatan yang jelas. Peralihan bukanlah pengganti untuk maklum balas pemuatan.
Pertukaran 3: Animasi tersuai atau lalai pelayar
Nilai lalai adalah lebih selamat dan lebih mudah diselenggara. Batalkan animasi elemen pseudo hanya dengan semantik navigasi yang jelas dan belanjawan pengesahan, serta sediakan keadaan statik yang sama berfungsi untuk pergerakan yang dikurangkan.
Latih tubi kegagalan dan pelan evolusi
Latih tubi 1: Pelayar tidak disokong atau panggilan balik ditolak
Kemas kini secara terus dalam pelayar yang tidak disokong, tolak Promise, dan sahkan keadaan halaman kekal betul. Log maklumat diagnostik sahaja dan jangan sekali-kali menyekat interaksi yang berterusan.
Latih tubi 2: Navigasi pantas dan perlumbaan tak segerak
Klik dua pautan dengan pantas sambil menjadikan permintaan pertama lebih perlahan. Sahkan bahawa peralihan lapuk tidak boleh menulis ganti keadaan semasa, fokus mendarat pada halaman semasa, dan tiada permintaan kesan sampingan pendua dihantar.
Latih tubi 3: Pergerakan yang dikurangkan dan peranti berspesifikasi rendah
Dayakan pergerakan kurangkan sistem dan jalankan peralihan senarai besar pada peranti yang terhad CPU. Sahkan animasi dilumpuhkan atau dipendekkan manakala kelewatan input dan kestabilan susun atur kekal dalam belanjawan.
Kesilapan lazim dan tindakan susulan
Kesilapan 1: Tiada laluan sandaran
API yang tidak disokong mesti tetap menghasilkan kemas kini DOM atau laluan yang sama. Peningkatan progresif tidak boleh mengikat keadaan perniagaan dengan kejayaan animasi.
Kesilapan 2: Menunggu rangkaian selama-lamanya di dalam panggilan balik
Penantian yang lama selepas snapshot membekukan halaman lama. Sediakan data lebih awal atau tetapkan had masa tamat dan langkau animasi.
Kesilapan 3: Memberikan satu nama yang dikongsi kepada banyak elemen
Nama pendua mewujudkan kekaburan pemadanan dan snapshot tambahan. Namakan hanya elemen yang benar-benar bergerak dan pastikan namanya unik serta stabil.
Kesilapan 4: Mengabaikan fokus dan tatalan
Peralihan visual yang selesai tidak mengembalikan pengguna papan kekunci ke tempat yang betul. Pulihkan fokus, tatalan dan tajuk semantik secara eksplisit.
Kesilapan 5: Menganggap pergerakan yang dikurangkan sebagai membuang ciri
Pengguna meminta pergerakan yang dikurangkan, bukannya pengurangan keadaan atau maklumat. Kekalkan interaksi yang sama dan ubah persembahan animasi sahaja.
Kesilapan 6: Mengundurkan keadaan perniagaan apabila animasi gagal
Penolakan finished biasanya menggambarkan kegagalan peringkat visual. Jangan serah semula atau undurkan kemas kini keadaan yang telah berjaya.