Temu duga Frontend: Bagaimanakah action.navigate harus bekerjasama dengan fallback klik?

1. Gesaan dan skop

Pemberitahuan status pesanan menawarkan tindakan Lihat pesanan, Sahkan penghantaran dan Hubungi sokongan. Aplikasi mungkin ditutup, tetingkap mungkin sudah wujud atau sesi mungkin telah tamat tempoh. Reka bentuk aliran dengan tindakan Notification dan terangkan cara navigasi pelayar bekerjasama dengan notificationclick.

2. Perkara yang sedang diuji oleh penemu duga

Memahami bahawa navigate badan dan navigate tindakan adalah URL yang berasingan, dengan URL tindakan mengambil keutamaan berbanding pengendalian tersuai.
Mengetahui bahawa tindakan tanpa URL akan sampai ke notificationclick, dan mengekalkan kerja tak segerak (async) dengan event.waitUntil.
Mengesahkan URL asal yang sama (same-origin), kebenaran, status pengesahan dan jangka hayat Service Worker.
Menggunakan tag, kunci keidempotenan perniagaan dan pemulihan klien untuk mengelakkan pengesahan atau tetingkap pendua.

3. Soalan untuk dijelaskan terlebih dahulu

Bolehkah Sahkan penghantaran menjadi navigasi GET, atau adakah ia mesti berupa API POST dengan pengesahan?
Patutkah sesi yang telah tamat tempoh membuka log masuk terlebih dahulu dan meneruskan tindakan selepas itu?
Bolehkah tindakan sokongan menyasarkan domain khidmat pelanggan luaran?
Patutkah tetingkap sedia ada difokuskan, dihantar mesej, atau patutkah tetingkap baharu dibuka?

4. Jawapan tiga puluh saat

Saya akan memetakan tindakan view dan help yang bersifat baca sahaja kepada URL same-origin dalam senarai dibenarkan, sambil membiarkan tindakan pengesahan yang mempunyai kesan sampingan tanpa navigate. Service Worker mengendalikan tindakan tersebut melalui API idempoten dan kemudian menghalakan ke halaman keputusan. Setiap URL disemak, kerja tak segerak dibungkus dalam waitUntil, dan tetingkap terkawal sedia ada difokuskan sebelum membuka fallback.

5. Penyelaman mendalam langkah demi langkah

Langkah 1: Isytiharkan URL badan 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 badan dan tindakan hendaklah laluan same-origin yang disahkan. Gunakan tag untuk mengemas kini atau menggabungkan pemberitahuan bagi satu pesanan, dan kekalkan data kepada pengecam tidak sensitif yang diperlukan untuk pemulihan.

Langkah 2: Asingkan tindakan baca sahaja dan tindakan dengan kesan sampingan

Tindakan view dan help hanya menavigasi dan boleh dikendalikan oleh pelayar. Sahkan tidak mempunyai navigate, jadi ia sampai ke notificationclick; ia mesti memanggil API pelayan yang idempoten dan bukannya mengekodkan perubahan keadaan dalam parameter pertanyaan.

Langkah 3: Laksanakan 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`)));
});

Kod pengeluaran harus menangkap kegagalan rangkaian, versi lapuk dan respons tanpa kebenaran serta membiarkan halaman keputusan membentangkan pemulihan. waitUntil memastikan acara Service Worker kekal hidup sehingga promise selesai.

Langkah 4: Kendalikan tetingkap dan pemulihan log masuk

focusOrOpen hendaklah memadankan tetingkap same-origin yang dikawal, menghantar laluan yang disahkan melalui postMessage, dan memanggil clients.openWindow hanya apabila tiada tetingkap yang sesuai wujud. Jika log masuk tamat tempoh, bawa hanya keadaan sasaran jangka pendek; selepas log masuk, halaman mesti mengambil dan membenarkan pesanan semula.

Langkah 5: Keselamatan, kebenaran dan keidempotenan

Kebenaran pemberitahuan mengawal paparan, bukan kebenaran pesanan. Hadkan protokol, asal dan laluan; gunakan ID pesanan, versi atau kunci keidempotenan untuk mengelakkan pengesahan pendua. Pembuangan, tag pendua dan klik peranti serentak memerlukan tingkah laku mesin keadaan (state-machine) pelayan yang jelas.

6. Model jawapan berkualiti tinggi

Saya akan menggunakan navigate same-origin untuk view dan help, serta mengendalikan Sahkan penghantaran dalam notificationclick kerana ia mempunyai kesan sampingan. Service Worker menggunakan waitUntil untuk memanggil API idempoten dengan versi pesanan dan kunci, kemudian memfokuskan tetingkap sedia ada atau membuka laluan keputusan. Setiap URL disenaraikan dalam senarai dibenarkan, kebenaran bukan pengesahan akses, dan pemulihan log masuk menyemak semula akses. Ujian meliputi klik badan dan tindakan, pengulangan, mod luar talian, versi lapuk dan berbilang tetingkap.

7. Kesilapan biasa

Mencetuskan pengesahan melalui URL GET → praambil (prefetch) atau pengulangan menyebabkan kesan sampingan → panggil POST idempoten daripada acara tersebut.
Menganggap tindakan tanpa URL membuka URL badan → tingkah laku adalah kabur → kendalikannya secara eksplisit dalam notificationclick.
Meletakkan keseluruhan pesanan dalam data → maklumat sensitif bocor → bawa pengecam sahaja dan ambil semula data yang dibenarkan.
Meninggalkan waitUntil di sekitar kerja tak segerak → Worker mungkin ditamatkan lebih awal → uruskan setiap promise kritikal.
Sentiasa mencipta tetingkap baharu → keadaan berpecah → padankan dan fokuskan tetingkap same-origin terlebih dahulu.

8. Soalan susulan

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

Apabila sesuatu tindakan mempunyai navigate tersendiri, pelayar boleh menggunakan URL tersebut. Tindakan tanpa token tersebut memerlukan pengendalian notificationclick tersuai.

Susulan 2: Mengapa tidak meletakkan pengesahan dalam URL?

Navigasi boleh dipraambil, dimainkan semula atau diklik berulang kali dan tidak boleh mewakili kesan sampingan dengan selamat. Pengesahan tergolong dalam peralihan keadaan pelayan yang dibenarkan dan idempoten.

Susulan 3: Bagaimanakah anda pulih daripada log masuk yang telah tamat tempoh?

Simpan keadaan sasaran jangka pendek yang dilindungi integriti semasa membuka log masuk. Selepas log masuk, halaman mengambil pesanan, menyemak kebenaran akses, dan kemudian memulihkan laluan keputusan.

Susulan 4: Bagaimanakah anda membuktikan tiada pelaksanaan pendua?

Cetuskan klik badan dan tindakan berulang kali merentas tetingkap dan peranti dengan versi pesanan dan kunci keidempotenan yang sama, kemudian pastikan bahawa pelayan hanya melakukan satu peralihan pengesahan.