Chrome 105 memperkenalkan dua metode baru di NavigateEvent Navigation API (diperkenalkan di 102) untuk meningkatkan metode yang terbukti bermasalah dalam praktik. 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 kedua metode tersebut dan cara metode baru memperbaiki masalah tersebut.
NavigateEvent.transitionWhile()
Metode NavigateEvent.trasitionWhile(), yang diperkenalkan dengan Navigation API di Chrome 102, mencegat navigasi untuk transisi sisi klien di aplikasi web satu halaman. Argumen pertamanya adalah promise yang memberi sinyal ke browser dan bagian lain aplikasi web bahwa promise tersebut telah selesai.
Dalam praktiknya, hal ini tidak berhasil. Pertimbangkan pola coding umum ini:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
Secara fungsional, ini setara dengan kode di bawah. Hal ini menyebabkan beberapa bagian navigasi berjalan sebelum API mengetahui bahwa developer bermaksud untuk mencegat navigasi.
doSyncStuff();
event.transitionWhile((async () => {
await doAsyncStuff();
})());
Salah satu contoh yang dapat mengacaukan aplikasi adalah dalam logika pemulihan scroll yang menangkap posisi scroll setelah perubahan DOM, bukan sebelumnya.
Yang berubah
Untuk mengganti transitionWhile(), spesifikasi saat ini memperkenalkan NavigateEvent.intercept(). Metode baru ini menggunakan pengendali selain properti focusReset dan scrollRestoration yang didukung oleh transitionWhile(). Pengendali baru selalu berjalan setelah navigasi di-commit, 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 intercept()
NavigateEvent.intercept() memiliki batasan yang sama dengan transitionWhile(), karena tidak dapat dipanggil di semua peristiwa navigasi. Navigasi lintas origin tidak dapat disadap, begitu juga dengan traversal lintas dokumen. Tindakan ini akan menampilkan DOMException dari jenis "SecurityError".
Untuk menggunakan intercept(), cukup teruskan pengendali kustom Anda saat memanggilnya.
navigation.addEventListener("navigate", event => {
event.intercept({
async handler() {
doSyncStuff();
await doAsyncStuff();
}
});
});
NavigateEvent.scroll()
Navigasi seperti dari bagian atas halaman ke anchor (sebut saja berpindah dari /a ke /a#id) ditangani sepenuhnya oleh browser bahkan di aplikasi web satu halaman. Namun, menavigasi ke anchor di 'halaman' lain (/a ke /b#id), yang sederhana untuk aplikasi multi halaman, lebih rumit untuk aplikasi web satu halaman. Aplikasi harus mengintersep navigasi ke /b#id menggunakan NavigateEvent.transitionWhile(), lalu memanggil NavigateEvent.restoreScroll() untuk menampilkan anchor. Seperti yang dinyatakan 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 kode Anda yang melakukannya.
Menggunakan scroll()
Secara default, browser akan mencoba menangani scroll secara otomatis, setelah pengendali intersepsi terpenuhi. Jika Anda ingin menangani scroll sendiri, tetapkan 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.