Chrome 105 memperkenalkan dua metode baru di NavigateEvent Navigation API (diperkenalkan pada versi 102) untuk meningkatkan kualitas metode yang terbukti bermasalah dalam praktiknya. intercept(), yang memungkinkan developer mengontrol status setelah navigasi, menggantikan transitionWhile(), yang terbukti sulit digunakan. Metode scroll(), yang men-scroll ke anchor yang ditentukan dalam URL, menggantikan restoreScroll() yang tidak berfungsi untuk semua jenis navigasi.
Dalam artikel ini, saya akan menjelaskan masalah pada keduanya dan bagaimana metode baru memperbaiki masalah tersebut.
NavigateEvent.transitionWhile()
Metode NavigateEvent.trasitionWhile(), yang diperkenalkan dengan Navigation API di Chrome 102, mencegat navigasi untuk transisi sisi klien dalam aplikasi web satu halaman. Argumen pertamanya adalah janji yang memberi tahu browser dan bagian lain aplikasi web bahwa prosesnya telah selesai.
Dalam praktiknya, cara ini tidak berfungsi dengan baik. Pertimbangkan pola coding umum ini:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
Secara fungsional, kode ini sama seperti kode di bawah. Hal ini menyebabkan beberapa bagian navigasi berjalan sebelum API mengetahui bahwa developer bermaksud mencegat navigasi.
doSyncStuff();
event.transitionWhile((async () => {
await doAsyncStuff();
})());
Salah satu contoh yang dapat mengacaukan aplikasi adalah dalam logika pemulihan scroll, yaitu ketika aplikasi menangkap posisi scroll setelah perubahan DOM, bukan sebelumnya.
Yang berubah
Untuk mengganti transitionWhile(), spesifikasi saat ini memperkenalkan NavigateEvent.intercept(). Metode baru ini mengambil pengendali selain properti focusReset dan scrollRestoration yang didukung oleh transitionWhile(). Pengendali baru selalu berjalan setelah commit navigasi, dan hal-hal seperti posisi scroll telah diambil, sehingga menghindari masalah dengan transitionWhile().
Metode transitionWhile() masih tersedia, tetapi tidak digunakan lagi dan akan dihapus di Chrome 108.
Menggunakan intersepsi()
NavigateEvent.intercept() memiliki batasan yang sama seperti transitionWhile(), karena tidak dapat dipanggil di semua peristiwa navigasi. Navigasi lintas asal tidak dapat disadap, dan juga traversal lintas dokumen tidak dapat dilakukan. Tindakan ini akan menampilkan DOMException dari jenis "SecurityError".
Untuk menggunakan intercept(), cukup teruskan pengendali kustom saat memanggilnya.
navigation.addEventListener("navigate", event => {
event.intercept({
async handler() {
doSyncStuff();
await doAsyncStuff();
}
});
});
NavigateEvent.scroll()
Navigasi seperti navigasi dari bagian atas halaman ke anchor (sebutnya berpindah dari /a ke /a#id) ditangani sepenuhnya oleh browser bahkan dalam aplikasi satu halaman. Namun, menavigasi ke anchor di 'halaman' lain (/a hingga /b#id), yang sederhana untuk aplikasi multi-halaman, lebih rumit untuk aplikasi web satu halaman. Aplikasi harus mencegat navigasi ke /b#id menggunakan NavigateEvent.transitionWhile(), lalu memanggil NavigateEvent.restoreScroll() untuk menampilkan anchor. Seperti yang disebutkan di atas, saat ini hal ini sulit dilakukan.
Yang berubah
Di aplikasi web satu halaman, Anda kini dapat mengontrol apakah browser menangani scroll ke anchor atau apakah kode Anda melakukannya.
Menggunakan scroll()
Secara default, browser akan berupaya menangani scroll secara otomatis, setelah penyadapan telah terpenuhi. Jika Anda ingin menangani scroll sendiri, setel scroll ke "manual", lalu panggil NavigateEvent.scroll() saat browser harus mencoba menetapkan posisi scroll.
navigation.addEventListener("manual", event => {
scroll: "manual",
event.intercept({
async handler() {
doSyncStuff();
// Handle scrolling earlier than by default:
event.scroll();
await doAsyncStuff();
}
});
});
Metode restoreScroll() masih tersedia, tetapi tidak digunakan lagi dan akan dihapus di Chrome 108.
Kesimpulan
Kami berharap dapat segera memperbarui artikel kami tentang Navigation API. Sementara itu, spesifikasi untuk API ini berisi banyak informasi khusus untuk developer web.