Chrome 105 memperkenalkan dua metode baru di NavigateEvent Navigation API (diperkenalkan pada versi 102) untuk meningkatkan kualitas metode yang dalam praktiknya terbukti bermasalah. 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 terkait keduanya 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 itu telah selesai.
Dalam praktiknya, ini tidak berjalan dengan baik. Pertimbangkan pola coding umum ini:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
Secara fungsional, kode ini sama dengan kode di bawah ini. 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 memungkinkan hal ini mengacaukan aplikasi adalah dalam logika pemulihan scroll yang menangkap posisi scroll setelah perubahan DOM, bukan sebelumnya.
Beberapa hal 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 navigasi di-commit, dan hal-hal seperti posisi scroll telah diambil untuk menghindari masalah pada transitionWhile().
Metode transitionWhile() masih tersedia, tetapi sudah tidak digunakan lagi dan akan dihapus di Chrome 108.
Menggunakan intersepsi()
NavigateEvent.intercept() memiliki batasan yang sama dengan transitionWhile(), karena di dalamnya tidak dapat dipanggil di semua peristiwa navigasi. Navigasi lintas asal tidak dapat dicegat, begitu juga 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 navigasi dari bagian atas halaman ke anchor (misalnya, berpindah dari /a ke /a#id) ditangani sepenuhnya oleh browser bahkan dalam aplikasi satu halaman. Namun, menavigasi ke anchor di 'halaman' lain (/a ke /b#id), yang sederhana untuk aplikasi multi-halaman, lebih rumit untuk aplikasi satu halaman. Aplikasi harus menangkap navigasi ke /b#id menggunakan NavigateEvent.transitionWhile(), lalu memanggil NavigateEvent.restoreScroll() untuk menampilkan anchor. Seperti yang disebutkan di atas, hal tersebut saat ini sulit dilakukan.
Beberapa hal yang berubah
Di aplikasi web satu halaman, Anda kini dapat mengontrol apakah browser menangani scroll ke anchor atau apakah kode Anda menanganinya.
Menggunakan scroll()
Secara default, browser akan mencoba menangani pengguliran secara otomatis, setelah hander intersepsi 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 sudah 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.