Frontend interview: Notification.navigate विश्वसनीय push deep links को कैसे सपोर्ट करता है?

1. Prompt और दायरा

एक ई-कॉमर्स Web Push notification को ऑर्डर विवरण खोलना चाहिए। ऐप बंद हो सकता है, कोई मौजूदा विंडो खुली हो सकती है, या उपयोगकर्ता किसी ऐक्शन को सक्रिय कर सकता है। navigate विकल्प के साथ deep link डिज़ाइन करें और URL पार्सिंग, permissions, क्लिक फ़ॉलबैक, डुप्लिकेट ओपनिंग, और Service Worker लाइफ़टाइम को कवर करें।

2. इंटरव्यूअर क्या टेस्ट कर रहा है

• यह जानना कि NotificationOptions.navigate एक नेविगेशन URL है और Notification.navigate इसके पार्स किए गए absolute URL या एक खाली स्ट्रिंग को प्रदर्शित करता है।
• डिफ़ॉल्ट notification navigation, action navigation, और notificationclick फ़ॉलबैक हैंडलिंग में अंतर करना।
• Permission, HTTPS, same-origin policy, open redirects, डुप्लिकेट नोटिफ़िकेशन, और मौजूदा विंडो के रीयूज़ को संभालना।
• ब्राउज़र नेविगेशन को ऑथराइजेशन मानने के बजाय रूट रिकवरी, ऑथेंटिकेशन, और idempotency को एप्लिकेशन लेयर में बनाए रखना।

3. पहले स्पष्ट करने योग्य प्रश्न

1. क्या पेज कोड या Service Worker showNotification को कॉल करता है?
2. क्या बाहरी URLs की अनुमति है, और साइन-इन के बाद एक ऑथेंटिकेटेड ऑर्डर पेज को कैसे फिर से शुरू होना चाहिए?
3. क्या बॉडी क्लिक और ऐक्शन क्लिक को अलग-अलग रूट्स खोलने चाहिए या अलग-अलग ऑपरेशन्स करने चाहिए?
4. जब एक same-origin विंडो मौजूद हो, तो क्या प्रोडक्ट को उस पर फ़ोकस करना चाहिए या कोई अन्य विंडो बनानी चाहिए?

4. तीस सेकंड का उत्तर

HTTPS के तहत, मैं Service Worker से एक persistent notification बनवाऊँगा जिसका navigate URL same-origin allowlist को पास करता हो। नेविगेशन URL वाली बॉडी या ऐक्शन को ब्राउज़र द्वारा हैंडल किया जा सकता है; बिना URL वाला ऐक्शन notificationclick पर फ़ॉलबैक करता है, जहाँ मैं किसी मौजूदा विंडो पर फ़ोकस करता हूँ या एक रिकवरी रूट खोलता हूँ। Permission, अमान्य URLs, और ऑथेंटिकेशन विफलताओं के लिए अभी भी स्पष्ट एप्लिकेशन हैंडलिंग की आवश्यकता होती है।

5. चरण-दर-चरण गहन विश्लेषण

चरण 1: एक मान्य notification URL बनाएं

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 को नोटिफिकेशन बनाते समय उपयोग किए गए बेस URL के सापेक्ष रिज़ॉल्व किया जाता है। सर्वर द्वारा प्रदान किए गए पाथ को same-origin और रूट-अलॉलिस्ट चेक्स पास करने होंगे; मनमाना यूज़र इनपुट कभी भी रीडायरेक्ट का टारगेट नहीं बनना चाहिए।

चरण 2: बॉडी और ऐक्शन नेविगेशन को अलग करें

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" },
  ],
});

जब कोई ऐक्शन सक्रिय होता है, तो उसका अपना navigate प्राथमिकता लेता है। उस URL के बिना कोई ऐक्शन notificationclick में प्रवेश करता है, जहाँ एप्लिकेशन-विशिष्ट व्यवहार चलता है। बॉडी और ऐक्शन रूट्स को एक ही allowlist और ऑथेंटिकेशन रिकवरी नियमों को साझा करना चाहिए।

चरण 3: क्लिक फ़ॉलबैक और मौजूदा विंडोज़ को संभालें

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")));
});

प्रोडक्शन कोड को विंडो URL को सत्यापित करना चाहिए, Service Worker कंट्रोल की प्रतीक्षा करनी चाहिए, और ऑर्डर को हार्ड-कोड करने के बजाय विश्वसनीय data पास करना चाहिए। ब्राउज़र एक टॉप-लेवल विंडो का पुनः उपयोग कर सकते हैं या एक नई विंडो बना सकते हैं, इसलिए एप्लिकेशन रिकवरी को दोनों परिणामों का समर्थन करना चाहिए।

चरण 4: Permissions, प्रोटोकॉल और सुरक्षा

नोटिफ़िकेशन के लिए यूज़र permission की आवश्यकता होती है, और persistent notifications के लिए Service Worker की आवश्यकता होती है; ये APIs एक secure context पर निर्भर करते हैं। Permission व्यावसायिक ऑथराइजेशन नहीं है: पेज खुलने के बाद ऑर्डर API को फिर से प्रमाणित करना होगा। ओपन रीडायरेक्ट्स और फ़िशिंग लिंक्स से बचने के लिए नेविगेशन को same-origin या स्पष्ट रूप से विश्वसनीय बाहरी origins तक सीमित करें।

चरण 5: स्थिति को idempotent रूप से पुनर्स्थापित करें

खोलने के बाद, रूट और data.orderId पढ़ें, लोडिंग स्थिति दिखाएं, फिर ऑर्डर प्राप्त करें और पहचान सत्यापित करें। समान tag वाले नोटिफ़िकेशन्स को प्रोडक्ट नीति के अनुसार मर्ज या अपडेट किया जाना चाहिए। रूट परिवर्तन, फ़ोकस पुनर्स्थापना, और एनालिटिक्स idempotent होने चाहिए ताकि एक क्लिक से डुप्लिकेट अनुरोध या स्टेट ट्रांज़िशन न बन सकें।

6. मॉडल उच्च-गुणवत्ता वाला उत्तर

मैं Service Worker को केवल allowlisted same-origin navigate URLs बनाने दूंगा और एक स्थिर tag असाइन करूँगा। एक बॉडी क्लिक ब्राउज़र नेविगेशन का अनुसरण करता है, जबकि एक ऐक्शन URL प्राथमिकता लेता है; बिना URL वाला ऐक्शन किसी मौजूदा विंडो पर फ़ोकस करने या फ़ॉलबैक खोलने के लिए notificationclick का उपयोग करता है। पेज फिर से ऑथेंटिकेट करता है, ऑर्डर पैरामीटर पढ़ता है, और idempotent रूप से स्टेट को रीस्टोर करता है। Permission, HTTPS, ओपन रीडायरेक्ट्स, और बाहरी URLs अलग चेक्स हैं; नोटिफिकेशन नेविगेशन कभी भी ऑथराइजेशन नहीं होता है।

7. सामान्य गलतियाँ

• यूज़र इनपुट को सीधे navigate में डालना → ओपन रीडायरेक्ट → same-origin और रूट allowlists लागू करें।
• यह मान लेना कि प्रत्येक क्लिक कस्टम कोड तक पहुँचता है → बॉडी नेविगेशन ब्राउज़र द्वारा हैंडल किया जा सकता है → केवल बिना URL वाले ऐक्शन्स के लिए notificationclick पर निर्भर रहें।
• नोटिफ़िकेशन permission को ऑर्डर ऑथराइजेशन मानना → डेटा एक्सपोज़र → पेज और API में फिर से ऑथेंटिकेट करें।
• हमेशा openWindow को कॉल करना → डुप्लिकेट विंडोज़ और अनुरोध → same-origin विंडोज़ का मिलान करें और रिकवरी को idempotent बनाएं।
• Service Worker लाइफ़टाइम को अनदेखा करना → एसिंक्रोनस कार्य बाधित हो जाता है → कंप्लीशन प्रॉमिस को event.waitUntil के अंदर रखें।

8. फॉलो-अप प्रश्न

फॉलो-अप 1: Notification.navigate क्या लौटाता है?

यह एक रीड-ओनली स्ट्रिंग है जिसमें नोटिफ़िकेशन का सीरियलाइज़्ड absolute navigation URL होता है, या कोई वैध URL सेट न होने पर एक खाली स्ट्रिंग होती है।

फॉलो-अप 2: क्या होता है जब किसी ऐक्शन में navigate नहीं होता है?

ऐक्शन अपने आप नेविगेट नहीं करता है। इसके एक्टिवेशन को Service Worker में notificationclick द्वारा हैंडल किया जा सकता है।

फॉलो-अप 3: पेज में फिर से ऑथेंटिकेट क्यों करें?

URL और data नेविगेशन संकेत हैं, पहचान या संसाधन ऑथराइजेशन नहीं। ऑर्डर API को वर्तमान सत्र और सर्वर-साइड permissions की फिर से जाँच करनी चाहिए।

फॉलो-अप 4: आप क्रॉस-विंडो व्यवहार का परीक्षण कैसे करते हैं?

कोई विंडो नहीं, एक मौजूदा same-origin विंडो, एक अनियंत्रित विंडो, बॉडी और ऐक्शन क्लिक्स, अस्वीकृत permission, और अमान्य URLs को कवर करें; सुनिश्चित करें कि एप्लिकेशन रिकवरी केवल एक अनुरोध करती है।