Wawancara Frontend: Bagaimana Notification.navigate mendukung deep link push yang andal?

1. Perintah dan cakupan

Sebuah Web Push notification e-commerce harus membuka detail pesanan. Aplikasi mungkin ditutup, jendela yang ada mungkin sedang terbuka, atau pengguna dapat mengaktifkan sebuah tindakan (action). Rancang deep link dengan opsi navigate dan cakup penguraian URL, izin, fallback klik, pembukaan duplikat, serta masa pakai (lifetime) Service Worker.

2. Hal yang diuji oleh pewawancara

• Mengetahui bahwa NotificationOptions.navigate adalah URL navigasi dan Notification.navigate mengekspos URL absolut hasil urai atau string kosong.
• Membedakan navigasi notifikasi bawaan, navigasi tindakan (action), dan penanganan fallback notificationclick.
• Menangani izin, HTTPS, same-origin policy, pengalihan terbuka (open redirects), notifikasi duplikat, dan penggunaan kembali jendela yang ada.
• Menjaga pemulihan rute, autentikasi, dan idempoten pada lapisan aplikasi alih-alih menganggap navigasi peramban sebagai otorisasi.

3. Pertanyaan yang perlu diperjelas terlebih dahulu

1. Apakah kode halaman atau Service Worker yang memanggil showNotification?
2. Apakah URL eksternal diizinkan, dan bagaimana halaman pesanan yang diautentikasi harus dilanjutkan kembali setelah masuk (sign-in)?
3. Apakah klik bodi dan klik tindakan harus membuka rute yang berbeda atau melakukan operasi yang berbeda?
4. Ketika jendela same-origin sudah ada, apakah produk harus memfokuskannya atau membuat jendela lain?

4. Jawaban tiga puluh detik

Di bawah HTTPS, saya akan membuat Service Worker membuat notifikasi persisten yang URL navigate-nya lolos allowlist same-origin. Bodi atau tindakan dengan URL navigasi dapat ditangani oleh peramban; tindakan tanpa URL akan beralih ke notificationclick, tempat saya memfokuskan jendela yang ada atau membuka rute pemulihan. Izin, URL yang tidak valid, dan kegagalan autentikasi tetap memerlukan penanganan eksplisit di aplikasi.

5. Pembahasan mendalam langkah demi langkah

Langkah 1: Buat URL notifikasi yang tervalidasi

const target = new URL(`/orders/${orderId}`, self.location.origin);

await self.registration.showNotification("Order shipped", {
  body: "View tracking details",
  tag: `order-${orderId}`,
  navigate: target.href,
  data: { orderId },
});

navigate diselesaikan terhadap URL dasar yang digunakan saat notifikasi dibuat. Jalur yang disediakan server harus lolos pemeriksaan same-origin dan allowlist rute; input pengguna sembarangan tidak boleh menjadi target pengalihan.

Langkah 2: Pisahkan navigasi bodi dan tindakan

await self.registration.showNotification("Order needs confirmation", {
  body: "Choose an action",
  navigate: "/orders/123",
  actions: [
    { action: "open", title: "View order", navigate: "/orders/123" },
    { action: "help", title: "Contact support" },
  ],
});

Ketika suatu tindakan diaktifkan, navigate miliknya sendiri yang diutamakan. Tindakan tanpa URL tersebut masuk ke notificationclick, tempat perilaku khusus aplikasi dijalankan. Rute bodi dan tindakan harus berbagi allowlist dan aturan pemulihan autentikasi yang sama.

Langkah 3: Tangani fallback klik dan jendela yang ada

self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  if (event.action === "help") {
    event.waitUntil(clients.openWindow("/support"));
    return;
  }
  event.waitUntil(clients.matchAll({ type: "window", includeUncontrolled: true })
    .then((windows) => windows[0]?.focus() ?? clients.openWindow("/orders/123")));
});

Kode produksi harus memverifikasi URL jendela, menunggu kontrol Service Worker, dan meneruskan data tepercaya alih-alih melakukan hard-coding pada pesanan. Peramban dapat menggunakan kembali atau membuat jendela tingkat atas (top-level), sehingga pemulihan aplikasi harus mendukung kedua hasil tersebut.

Langkah 4: Izin, protokol, dan keamanan

Notifikasi memerlukan izin pengguna, dan notifikasi persisten memerlukan Service Worker; API ini bergantung pada konteks aman (secure context). Izin bukanlah otorisasi bisnis: API pesanan harus melakukan autentikasi ulang setelah halaman terbuka. Batasi navigasi ke same-origin atau origin eksternal yang dipercaya secara eksplisit untuk menghindari pengalihan terbuka dan tautan phishing.

Langkah 5: Pulihkan status secara idempoten

Setelah terbuka, baca rute dan data.orderId, tampilkan status memuat (loading state), lalu ambil data pesanan dan verifikasi identitas. Notifikasi dengan tag yang sama harus digabungkan atau diperbarui sesuai dengan kebijakan produk. Perubahan rute, pemulihan fokus, dan analitik harus bersifat idempoten sehingga satu klik tidak dapat membuat permintaan duplikat atau transisi status berulang.

6. Contoh jawaban berkualitas tinggi

Saya akan mengizinkan Service Worker hanya membuat URL navigate same-origin yang masuk dalam allowlist dan menetapkan tag yang stabil. Klik bodi mengikuti navigasi peramban, sedangkan URL tindakan lebih diutamakan; tindakan tanpa URL menggunakan notificationclick untuk memfokuskan jendela yang ada atau membuka fallback. Halaman mengautentikasi ulang, membaca parameter pesanan, dan memulihkan status secara idempoten. Izin, HTTPS, pengalihan terbuka, dan URL eksternal adalah pemeriksaan terpisah; navigasi notifikasi tidak pernah menjadi otorisasi.

7. Kesalahan umum

• Menempatkan input pengguna langsung ke dalam navigate → open redirect → terapkan allowlist same-origin dan rute.
• Menganggap setiap klik sampai ke kode kustom → navigasi bodi dapat ditangani oleh peramban → andalkan notificationclick hanya untuk tindakan tanpa URL.
• Memperlakukan izin notifikasi sebagai otorisasi pesanan → paparan data → autentikasi ulang di halaman dan API.
• Selalu memanggil openWindow → jendela dan permintaan duplikat → cocokkan jendela same-origin dan buat pemulihan menjadi idempoten.
• Mengabaikan masa pakai (lifetime) Service Worker → pekerjaan asinkron terputus → pertahankan promise penyelesaian di dalam event.waitUntil.

8. Pertanyaan lanjutan

Pertanyaan lanjutan 1: Apa yang dikembalikan oleh Notification.navigate?

Ini adalah string read-only yang berisi URL navigasi absolut notifikasi yang diserialisasi, atau string kosong jika tidak ada URL valid yang ditetapkan.

Pertanyaan lanjutan 2: Apa yang terjadi jika sebuah tindakan tidak memiliki navigate?

Tindakan tersebut tidak bernavigasi secara otomatis. Aktivasinya dapat ditangani oleh notificationclick di Service Worker.

Pertanyaan lanjutan 3: Mengapa harus melakukan autentikasi ulang di halaman?

URL dan data hanyalah petunjuk navigasi, bukan otorisasi identitas atau sumber daya. API pesanan harus memeriksa kembali sesi saat ini dan izin di sisi server.

Pertanyaan lanjutan 4: Bagaimana cara menguji perilaku lintas-jendela (cross-window)?

Cakup skenario tanpa jendela, jendela same-origin yang ada, jendela yang tidak terkontrol, klik bodi dan tindakan, izin yang ditolak, dan URL yang tidak valid; pastikan pemulihan aplikasi hanya membuat satu permintaan.