Wawancara Frontend: Bagaimana seharusnya action.navigate bekerja sama dengan fallback klik?

1. Perintah dan cakupan

Notifikasi status pesanan menawarkan tindakan Lihat pesanan, Konfirmasi pengiriman, dan Hubungi dukungan. Aplikasi mungkin ditutup, jendela mungkin sudah ada, atau sesi mungkin telah kedaluwarsa. Rancang alur dengan tindakan Notification dan jelaskan bagaimana navigasi peramban bekerja sama dengan notificationclick.

2. Apa yang sedang diuji oleh pewawancara

Memahami bahwa navigate pada bodi dan navigate pada tindakan adalah URL yang terpisah, dengan URL tindakan lebih diprioritaskan daripada penanganan kustom.
Mengetahui bahwa tindakan tanpa URL akan diteruskan ke notificationclick, dan menjaga pekerjaan asinkron tetap berjalan dengan event.waitUntil.
Memvalidasi URL asal yang sama (same-origin), izin, status autentikasi, dan masa aktif Service Worker.
Menggunakan tag, kunci idempotensi bisnis, dan pemulihan klien untuk menghindari konfirmasi atau jendela duplikat.

3. Pertanyaan untuk diklarifikasi terlebih dahulu

Apakah Konfirmasi pengiriman boleh berupa navigasi GET, atau harus berupa API POST dengan konfirmasi?
Apakah sesi yang kedaluwarsa harus membuka login terlebih dahulu dan melanjutkan tindakan setelahnya?
Bolehkah tindakan dukungan menargetkan domain layanan pelanggan eksternal?
Apakah jendela yang ada harus difokuskan, dikirimi pesan, atau haruskah jendela baru dibuka?

4. Jawaban tiga puluh detik

Saya akan memetakan tindakan view dan help yang bersifat hanya-baca ke URL same-origin yang diizinkan (allowlist), sambil membiarkan tindakan konfirmasi yang memiliki efek samping tanpa navigate. Service Worker menangani tindakan tersebut melalui API yang idempoten lalu merutekan ke halaman hasil. Setiap URL diperiksa, pekerjaan asinkron dibungkus dalam waitUntil, dan jendela terkontrol yang ada difokuskan sebelum membuka fallback.

5. Pembahasan mendalam langkah demi langkah

Langkah 1: Deklarasikan URL bodi dan tindakan

await self.registration.showNotification("Order #123", {
  body: "Choose an action",
  tag: "order-123",
  navigate: "/orders/123",
  data: { orderId: "123", version: 4 },
  actions: [
    { action: "view", title: "View order", navigate: "/orders/123" },
    { action: "confirm", title: "Confirm delivery" },
    { action: "help", title: "Contact support", navigate: "/support/orders/123" },
  ],
});

URL bodi dan tindakan harus berupa rute same-origin yang divalidasi. Gunakan tag untuk memperbarui atau menggabungkan notifikasi untuk satu pesanan, dan batasi data pada pengidentifikasi non-sensitif yang diperlukan untuk pemulihan.

Langkah 2: Pisahkan tindakan hanya-baca dan tindakan dengan efek samping

Tindakan view dan help hanya melakukan navigasi dan dapat ditangani oleh peramban. Konfirmasi tidak memiliki navigate, sehingga diteruskan ke notificationclick; tindakan ini harus memanggil API server yang idempoten daripada menyandikan perubahan status dalam parameter kueri.

Langkah 3: Terapkan fallback notificationclick

self.addEventListener("notificationclick", (event) => {
  event.notification.close();
  const { orderId, version } = event.notification.data ?? {};
  if (event.action !== "confirm" || !orderId) return;

  event.waitUntil(confirmDelivery(orderId, version).then(() =>
    focusOrOpen(`/orders/${encodeURIComponent(orderId)}?confirmed=1`)));
});

Kode produksi harus menangkap kegagalan jaringan, versi usang, dan respons tanpa izin serta membiarkan halaman hasil menampilkan pemulihan. waitUntil menjaga event Service Worker tetap aktif hingga promise selesai.

Langkah 4: Tangani jendela dan pemulihan login

focusOrOpen harus mencocokkan jendela same-origin yang terkontrol, mengirim rute yang telah divalidasi melalui postMessage, dan memanggil clients.openWindow hanya jika tidak ada jendela yang sesuai. Jika login kedaluwarsa, bawa hanya status target yang berumur pendek; setelah masuk, halaman harus mengambil dan mengotorisasi pesanan lagi.

Langkah 5: Keamanan, izin, dan idempotensi

Izin notifikasi mengontrol tampilan, bukan otorisasi pesanan. Batasi protokol, origin, dan jalur; gunakan ID pesanan, versi, atau kunci idempotensi untuk mencegah konfirmasi duplikat. Penolakan, tag duplikat, dan klik perangkat simultan memerlukan perilaku state-machine server yang eksplisit.

6. Contoh jawaban berkualitas tinggi

Saya akan menggunakan navigate same-origin untuk view dan help, serta menangani Konfirmasi pengiriman di notificationclick karena memiliki efek samping. Service Worker menggunakan waitUntil untuk memanggil API idempoten dengan versi pesanan dan kuncinya, kemudian memfokuskan jendela yang ada atau membuka rute hasil. Setiap URL dimasukkan ke dalam daftar yang diizinkan, izin bukanlah otorisasi, dan pemulihan login memeriksa ulang akses. Pengujian mencakup klik bodi dan tindakan, pengulangan, mode offline, versi usang, dan beberapa jendela.

7. Kesalahan umum

Memicu konfirmasi melalui URL GET → prefetch atau pengulangan menyebabkan efek samping → panggil POST yang idempoten dari event.
Menganggap tindakan tanpa URL akan membuka URL bodi → perilakunya ambigu → tangani secara eksplisit di notificationclick.
Menaruh pesanan lengkap di data → informasi sensitif bocor → bawa pengidentifikasi saja dan ambil ulang data yang terotorisasi.
Menghilangkan waitUntil di sekitar pekerjaan asinkron → Worker mungkin berhenti sebelum waktunya → kelola setiap promise penting.
Selalu membuat jendela baru → status terpecah → cocokkan dan fokuskan jendela same-origin terlebih dahulu.

8. Pertanyaan lanjutan

Lanjutan 1: Mana yang menang, action.navigate atau notificationclick?

Ketika sebuah tindakan memiliki navigate sendiri, peramban dapat menggunakan URL tersebut. Tindakan tanpa token tersebut memerlukan penanganan notificationclick kustom.

Lanjutan 2: Mengapa tidak menaruh konfirmasi di URL?

Navigasi dapat di-prefetch, diputar ulang, atau diklik berulang kali dan tidak dapat secara aman merepresentasikan efek samping. Konfirmasi merupakan bagian dari transisi status server yang terotorisasi dan idempoten.

Lanjutan 3: Bagaimana cara memulihkan dari login yang kedaluwarsa?

Simpan status target berumur pendek yang terlindungi integritasnya saat membuka login. Setelah masuk, halaman mengambil pesanan, memeriksa otorisasi, lalu memulihkan rute hasil.

Lanjutan 4: Bagaimana cara membuktikan tidak ada eksekusi ganda?

Picu klik bodi dan tindakan berulang kali di seluruh jendela dan perangkat dengan versi pesanan dan kunci idempotensi yang sama, lalu pastikan bahwa server hanya melakukan satu kali transisi konfirmasi.