Topik temu duga representatif

Temu Duga Frontend: Peningkatan Progresif dengan View Transition API

FrontendSederhana
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Reka bentuk penyelesaian View Transition API untuk navigasi SPA dan pelbagai halaman, termasuk sandaran untuk pelayar yang tidak disokong, pergerakan dikurangkan dan peralihan yang gagal.

Gesaan dan konteks

Sebuah produk inginkan peralihan yang koheren antara paparan senarai, butiran dan tapisan tanpa mengorbankan navigasi natif, kebolehcapaian atau prestasi peranti kelas rendah. Reka bentuk pelan peningkatan progresif: gunakan document.startViewTransition() untuk kemas kini dokumen sama, pengisytiharan CSS untuk navigasi rentas dokumen, dan terangkan tingkah laku apabila API tidak tersedia, kemas kini DOM gagal atau pengguna memilih pergerakan dikurangkan.

Ini sesuai untuk peranan frontend, sistem reka bentuk dan prestasi. MDN, Chrome for Developers dan spesifikasi CSS View Transitions mentakrifkan kitaran hayat ViewTransition, mekanisme dokumen sama dan rentas dokumen, pepohon animasi pseudo-elemen serta tingkah laku langkau. Artikel ini diperoleh daripada piawaian awam, bukan dakwaan tentang bank soalan temu duga sesebuah syarikat.

Perkara yang dinilai oleh penemu duga

Penemu duga sedang menguji sama ada anda memisahkan semantik navigasi, kemas kini DOM, kitaran hayat animasi dan sempadan sandaran. Jawapan yang kukuh menyebut tentang ready, updateCallbackDone, finished, skipTransition(), prefers-reduced-motion, nilai unik view-transition-name dan had asal yang sama (same-origin). Jawapan yang lemah menambah peraturan CSS lenyap-masuk (fade-in) tanpa pelan kegagalan.

Soalan penjelasan

  • Adakah sasarannya perubahan keadaan SPA, navigasi rentas dokumen atau kedua-duanya?
  • Elemen manakah yang memerlukan identiti kongsi, dan adakah kad senarai mempunyai ID yang stabil apabila membuka butiran?
  • Adakah navigasi teras dan pengindeksan mesti berfungsi tanpa JavaScript?
  • Apakah tempoh animasi, belanjawan peranti kelas rendah dan keperluan pergerakan dikurangkan yang dimiliki oleh produk?

Jawapan 30 saat

“Saya akan mengekalkan navigasi natif dan kemas kini keadaan sebagai punca kebenaran (source of truth) dan menggunakan View Transitions sebagai peningkatan progresif. Untuk SPA, balut kemas kini DOM segerak atau tak segerak dalam startViewTransition(update) dan animasikan pseudo-elemen selepas ready; untuk navigasi pelbagai halaman, gunakan @view-transition { navigation: auto; } asal yang sama dengan nama yang stabil untuk elemen kongsi. Jika API tiada, kemas kini gagal atau pergerakan dikurangkan diminta, selesaikan kemas kini tanpa animasi dan panggil skipTransition() apabila diperlukan. Nama unik, had masa tamat (timeout) dan metrik menghalang peralihan daripada menyekat tingkah laku produk.”

Penyelesaian langkah demi langkah

Untuk peralihan dokumen sama, panggil document.startViewTransition(() => update()). Pelayar menangkap keadaan lama, menjalankan panggilan balik kemas kini dan mencipta keadaan baharu; ViewTransition yang dikembalikan mendedahkan Janji (Promise) ready, updateCallbackDone dan finished. Jika panggilan balik melontarkan ralat, aplikasi masih bertanggungjawab terhadap pengendalian ralat; penyerahan perniagaan tidak boleh bergantung pada kejayaan animasi. Sesuaikan peralihan dengan pseudo-elemen seperti ::view-transition-old(root) dan ::view-transition-new(root).

Gunakan view-transition-name untuk memadankan elemen lama dengan rakan sejawatannya yang baharu. Nama mestilah unik dalam satu pepohon peralihan. Senarai memerlukan ID perniagaan yang stabil dan bukannya indeks tatasusunan, jika tidak, pengisihan atau penapisan akan memadankan elemen yang salah. Namakan hanya elemen penting; terlalu banyak tangkapan syot kilat dan permukaan penggubah (compositor) meningkatkan kos.

Peralihan rentas dokumen bergantung pada navigasi asal yang sama dan pengisytiharan CSS @view-transition; JavaScript tidak memanggil startViewTransition() untuk navigasi tersebut. Ini berfungsi untuk aplikasi pelbagai halaman tetapi bergantung pada sokongan pelayar, dasar asal yang sama dan CSS halaman. Pautan mesti masih boleh menavigasi seperti biasa tanpa peralihan; Janji animasi tidak boleh menyekat respons pelayan atau tingkah laku pautan lalai.

Pengendalian kitaran hayat memerlukan laluan masa tamat dan langkau. Jika ready tidak diselesaikan dalam belanjawan masa, rekodkan sebabnya dan panggil skipTransition(). Navigasi kembali, penyerahan borang dan meninggalkan halaman harus mengutamakan navigasi. Gunakan finished hanya untuk pembersihan dan metrik, jangan sekali-kali sebagai bukti bahawa data telah disimpan. Untuk data tak segerak, tentukan sempadan komit keadaan sebelum memutuskan sama ada untuk menunggu peralihan.

Kebolehcapaian bermaksud menghormati @media (prefers-reduced-motion: reduce) dengan menetapkan tempoh animasi kepada sifar atau melangkauinya. Kekalkan fokus, tajuk dan susunan bacaan; kedudukan visual tidak boleh menggantikan kemas kini semantik. Pengguna papan kekunci, pembaca skrin dan peranti perlahan mesti menerima hasil kandungan yang sama.

Peningkatan progresif menggabungkan pengesanan keupayaan dengan sandaran navigasi sebenar. Jika document.startViewTransition tiada, panggil fungsi kemas kini secara terus; jika sokongan rentas dokumen tiada, kekalkan pautan biasa. Ukur kadar sokongan, kadar langkau, kependaman ready, kadar bingkai dan kependaman interaksi mengikut pelayar dan peranti. Peralihan boleh mengubah persembahan, tetapi tidak sekali-kali ketepatan cache, kebenaran, penyerahan borang atau penghalaan.

Model jawapan

Saya akan mengekalkan navigasi dan penyerahan keadaan bebas daripada animasi. SPA menggunakan startViewTransition(update) dan menganimasikan hanya elemen kongsi penting selepas ready; aplikasi pelbagai halaman menggunakan @view-transition asal yang sama. Setiap elemen kongsi mendapat nama perniagaan yang stabil dan unik, dan kemas kini tak segerak yang gagal akan melangkau peralihan sambil menunjukkan keadaan ralat biasa.

Pelayar yang tidak disokong menggunakan kemas kini natif atau pautan biasa. Pengguna pergerakan dikurangkan tidak mendapat animasi atau animasi yang dipendekkan. Masa tamat kitaran hayat mengekalkan skipTransition(). Fokus, tajuk dan susunan semantik tidak pernah bergantung pada kesan visual. Pantau sokongan, langkauan dan kependaman interaksi, kemudian kembangkan set elemen bernama selepas ujian kenari (canary).

Kesilapan biasa

  • Kesilapan → menggunakan indeks tatasusunan sebagai view-transition-name; Sebab ia gagal → pengisihan memadankan nod lama dan baharu yang salah; Penyelesaian → gunakan ID perniagaan yang stabil dan kuat kuasakan keunikan.
  • Kesilapan → menunggu finished sebelum menyerahkan borang; Sebab ia gagal → kegagalan animasi menyekat tindakan perniagaan; Penyelesaian → komit keadaan dahulu dan animasikan persembahan sahaja.
  • Kesilapan → hanya mereka bentuk laluan SPA; Sebab ia gagal → navigasi pelbagai halaman tidak mempunyai tapak panggilan JavaScript; Penyelesaian → gunakan @view-transition asal yang sama dan kekalkan pautan biasa.
  • Kesilapan → mengabaikan keutamaan pergerakan dikurangkan; Sebab ia gagal → pengguna yang sensitif mungkin mengalami pening atau beban kognitif; Penyelesaian → pendekkan atau langkau animasi dalam pertanyaan media.

Soalan susulan

Bagaimanakah panggilan balik kemas kini yang gagal mempengaruhi peralihan dan keadaan?

Anggap panggilan balik kemas kini sebagai sempadan keadaan perniagaan: tangkap pengecualian, undurkan (rollback) atau paparkan ralat, dan kekalkan Janji peralihan terhad kepada kitaran hayat animasi. Jika updateCallbackDone menolak (reject), panggil skipTransition() atau biarkan pelayar menyelesaikan persembahan lalai; jangan sembunyikan ralat tersebut.

Mengapakah tidak menamakan setiap elemen sebagai elemen kongsi?

Setiap nama mesti membentuk pasangan yang jelas antara pepohon lama dan baharu. Menamakan semua perkara meningkatkan kos tangkapan, reka letak dan gubahan serta boleh mewujudkan padanan yang tidak disengajakan. Namakan hanya objek utama yang difahami pengguna; gunakan lenyap punca (root fade) atau tiada animasi untuk selebihnya.

Bagaimanakah anda membuktikan peralihan tidak menjejaskan prestasi?

Ukur kependaman ready, kadar bingkai, tugas panjang (long tasks), kependaman input pertama dan kadar langkau mengikut pelayar dan peranti, kemudian uji saiz senarai yang realistik. Jika peranti kelas rendah menunjukkan kehilangan bingkai yang berterusan, kurangkan skop animasi atau langkau secara automatik sambil mengekalkan masa navigasi tidak berubah.

Sumber awam

Soalan berkaitan