प्रॉम्प्ट और संदर्भ
एक सर्च पेज सुझावों, प्रोफ़ाइल डेटा और परिणामों के लिए समवर्ती रूप से रिक्वेस्ट करता है। एक नई क्वेरी या नेविगेशन को पुराने कार्य को तुरंत रद्द कर देना चाहिए; अटकी हुई नेटवर्क रिक्वेस्ट का टाइमआउट होना चाहिए, लेकिन बैकग्राउंड से लौटने पर फ़्रीज़ किए गए समय को ऑनलाइन रिक्वेस्ट समय के रूप में नहीं गिना जाना चाहिए। AbortSignal.timeout(), AbortSignal.any() और AbortController के साथ कैंसलेशन डिज़ाइन करें।
यह फ्रंटएंड, वेब परफॉर्मेंस और एसिंक्रोनस-आर्किटेक्चर इंटरव्यू के लिए उपयुक्त है। मुख्य बात यह है कि हर अपवाद को "रिक्वेस्ट टाइम आउट हो गई" के रूप में दिखाने के बजाय यूज़र अबॉर्ट, टाइमआउट, पेज लाइफ़साइकिल और वास्तविक नेटवर्क विफलताओं को अलग-अलग किया जाए।
इंटरव्यूअर क्या जांच रहा है
एक सटीक उत्तर बताता है कि AbortSignal.timeout() एक ऐसा सिग्नल लौटाता है जो TimeoutError के साथ अपने आप रद्द हो जाता है; यूज़र या कंट्रोलर का अबॉर्ट आमतौर पर एक AbortError होता है। यह एक्टिव-टाइम सिमेंटिक्स को भी समझाता है: जब कोई पेज bfcache में होता है या कोई Worker निलंबित होता है, तो टाइमर रुक जाता है। एक निदान योग्य कारण को बनाए रखते हुए AbortSignal.any() के साथ कई सिग्नल्स को जोड़ा जा सकता है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- कौन सी रिक्वेस्ट्स को रद्द करना सुरक्षित है, और क्या राइट्स को पूरा होना चाहिए या बाद में उनकी स्थिति जांची जानी चाहिए?
- क्या टाइमआउट यूज़र एक्शन, रिक्वेस्ट डिस्पैच या पेज विजिबिलिटी पर शुरू होता है?
- क्या यूज़र अबॉर्ट, अनमाउंट, नेविगेशन और टाइमआउट के लिए अलग-अलग मैसेजिंग की आवश्यकता है?
- क्या लक्षित ब्राउज़र स्टैटिक मेथड्स का समर्थन करते हैं, और क्या फ़ॉलबैक को एक मैनुअल टाइमर बनाए रखना चाहिए?
- पुनः प्रयास (retries), डिडुप्लिकेशॅन, कैशिंग और रिज़ल्ट रेस को कैसे संभाला जाता है?
30-सेकंड का उत्तर ढांचा
"प्रत्येक रिक्वेस्ट के लिए मैं यूज़र कैंसलेशन को AbortSignal.timeout() के साथ जोड़ूँगा और TimeoutError, AbortError और नेटवर्क त्रुटियों को अलग-अलग वर्गीकृत करूँगा। टाइमआउट एक्टिव टाइम का उपयोग करता है, इसलिए सस्पेंशन या bfcache को ऑनलाइन लेटेंसी के रूप में रिपोर्ट नहीं किया जाना चाहिए। एक नई क्वेरी पुराने कंट्रोलर को रद्द कर देती है, और रिज़ल्ट सबमिशन भी एक रिक्वेस्ट सीक्वेंस या सिग्नल की जांच करता है ताकि पुराना डेटा प्राथमिकता न ले सके। पुराने ब्राउज़रों को एक कंट्रोलर-प्लस-टाइमर फ़ॉलबैक मिलता है, जिसका परीक्षण कैंसलेशन, टाइमआउट, रिज्यूम और रेस के लिए किया जाता है।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: तीन कैंसलेशन स्रोतों को अलग करें
AbortController.abort() एप्लिकेशन द्वारा शुरू किया जाता है; AbortSignal.timeout(ms) तब रद्द होता है जब एक्टिव टाइम एक सीमा तक पहुंच जाता है; AbortSignal.any([...]) तब ट्रिगर होता है जब कोई भी इनपुट सिग्नल रद्द हो जाता है। सभी को fetch में पास किया जा सकता है, लेकिन व्यावसायिक परत (business layer) को कारण बनाए रखना चाहिए ताकि पेज छोड़ने को सेवा विफलता के रूप में लॉग न किया जाए।
const controller = new AbortController();
const timeout = AbortSignal.timeout(5000);
const signal = AbortSignal.any([controller.signal, timeout]);
fetch(url, { signal });चरण 2: कारण के आधार पर वर्गीकृत करें
टाइमआउट TimeoutError DOMException का उपयोग करता है; यूज़र कैंसलेशन या ब्राउज़र स्टॉप आमतौर पर AbortError का उपयोग करता है। DNS, कनेक्शन रीसेट और CORS समस्याएं अन्य त्रुटियों के रूप में दिखाई दे सकती हैं। एक्सेप्शन को कैच करने वाले कोड को मैसेजिंग, पुनः प्रयास और लॉग गंभीरता चुनने से पहले signal.reason या एक्सेप्शन के नाम का निरीक्षण करना चाहिए।
चरण 3: एक्टिव टाइम को समझें
timeout() एक साधारण वॉल क्लॉक के बजाय एक्टिव टाइम को मापता है। दस्तावेज़ बताते हैं कि जब कोई पेज bfcache में होता है या कोई Worker निलंबित होता है, तो टाइमर रुक जाता है। यह यूज़र द्वारा अनुभव की जाने वाली एक्टिव रिक्वेस्ट विंडो के लिए उपयुक्त है, न कि सर्वर की पूर्ण समय सीमा (absolute server deadline) के लिए; सर्वर को अभी भी अपनी स्वयं की टाइमआउट और आइडेम्पोटेंसी नीति की आवश्यकता होती है।
चरण 4: सर्च रेस को संभालें
जब यूज़र बार-बार टाइप करता है, तो नई क्वेरी के लिए सिग्नल बनाने से पहले पुराने कंट्रोलर को अबॉर्ट करें। भले ही पुराना नेटवर्क कार्य पूरा हो गया हो, उसका कॉलबैक अभी भी कतार में हो सकता है; स्थिति कमिट करने से पहले रिक्वेस्ट सीक्वेंस, वर्तमान क्वेरी या signal.aborted की जांच करें। केवल कैंसलेशन रिज़ल्ट-वर्जन ऑर्डरिंग प्रदान नहीं करता है।
चरण 5: कैंसल करने योग्य रीड्स और राइट्स को अलग करें
सर्च, इमेज और सुझाव रीड्स आमतौर पर कैंसल करने योग्य होते हैं। भुगतान, ऑर्डर या अपलोड राइट्स पहले ही सर्वर पर प्रभावी हो चुके हो सकते हैं। क्लाइंट के इंतज़ार को रद्द करने से सर्वर का साइड इफेक्ट पूर्ववत नहीं होता है। केवल एक छोटा टाइमआउट चुनने के बजाय राइट्स के लिए idempotency कीज, स्टेटस क्वेरी या बैकग्राउंड टास्क का उपयोग करें।
चरण 6: सिग्नल लाइफ़टाइम डिज़ाइन करें
अनमाउंट पर कंपोनेंट कंट्रोलर को अबॉर्ट करें, नेविगेशन पर पेज-लेवल सिग्नल का पुनः उपयोग करें, और व्यक्तिगत ऑपरेशन के लिए रिक्वेस्ट टाइमआउट जोड़ें। बाद की रिक्वेस्ट्स के साथ स्थायी रूप से अबॉर्ट किए गए ग्लोबल सिग्नल को कभी साझा न करें; प्रति ऑपरेशन एक नया सिग्नल बनाएं। जब डायग्नोस्टिक्स महत्वपूर्ण हों तो विभिन्न स्रोतों को स्पष्ट कारण प्रदान करें।
चरण 7: कम्पैटिबिलिटी फ़ॉलबैक प्रदान करें
यदि किसी पुराने ब्राउज़र में AbortSignal.timeout या any का अभाव है, तो AbortController को setTimeout के साथ संयोजित करें, टाइमर को साफ़ करें और कारण को सामान्यीकृत करें। फ़ीचर डिटेक्शन रनटाइम पर होना चाहिए, और डिफ़ॉल्ट पाथ को अभी भी स्टैटिक मेथड्स के बिना वातावरण को संभालना चाहिए।
चरण 8: लाइफ़साइकिल और क्लीनअप सत्यापित करें
तेज़ इनपुट, अनमाउंट, नेविगेशन, बैकग्राउंड सस्पेंशन, bfcache रीस्टोर, टाइमआउट, यूज़र अबॉर्ट, नेटवर्क विफलता और बार-बार पुनः प्रयासों का परीक्षण करें। पुष्टि करें कि रिक्वेस्ट रद्द हो गई है, टाइमर साफ़ हो गए हैं, पुराने रिज़ल्ट कमिट नहीं हो सकते हैं, संदेश सटीक हैं, और एक्सेप्शन को कैच करने से अनहैंडल्ड प्रॉमिस या स्टेट-अपडेट चेतावनियां उत्पन्न नहीं होती हैं।
ट्रेड-ऑफ और सीमाएं
मर्ज किए गए सिग्नल्स कैंसलेशन ग्लू कोड को कम करते हैं, लेकिन वे सर्वर ट्रांजेक्शन को प्रतिवर्ती (reversible) नहीं बनाते हैं या यह गारंटी नहीं देते हैं कि रिस्पॉन्स कभी नहीं आएगा। एक्टिव-टाइम सिमेंटिक्स यूज़र अनुभव के अनुकूल हैं लेकिन एंड-टू-एंड SLA के लिए नहीं। सर्वर की समय सीमा के साथ समन्वय करते हुए, रिक्वेस्ट प्रकार, नेटवर्क स्थितियों और पुनः प्रयास बजट के आधार पर टाइमआउट मान निर्धारित करें।
टाइमआउट का अनुकरण करने और अंतर्निहित रिक्वेस्ट को चालू रखने के लिए केवल Promise.race का उपयोग न करें। AbortSignal पास करें ताकि नेटवर्क और संसाधन रुक सकें। प्रत्येक अबॉर्ट को त्रुटि के रूप में लॉग न करें, अन्यथा सामान्य नेविगेशन अलर्ट्स को दूषित कर देगा।
रोलआउट योजना और प्रमाण
सर्च रीड्स के लिए रिक्वेस्ट स्टेट मशीन से शुरुआत करें: सिग्नल बनाएं, डिस्पैच करें, कारण वर्गीकृत करें, एक वर्जन वाले रिज़ल्ट को कमिट करें, और अनमाउंट पर अबॉर्ट करें। संवेदनशील क्वेरी टेक्स्ट के बिना रिक्वेस्ट का प्रकार, कारण, एक्टिव अवधि, पुनः प्रयास गणना और अंतिम स्थिति रिकॉर्ड करें।
bfcache, Workers, धीमे नेटवर्क और तेज़ इनपुट में समर्थित और फ़ॉलबैक ब्राउज़रों की तुलना करें। स्वीकृति के लिए आवश्यक है कि कोई पुराना रिज़ल्ट ओवरराइट न हो, कोई टाइमर लीक न हो, सटीक कैंसलेशन संदेश हो, कोई आकस्मिक राइट अबॉर्ट न हो, और सर्वर idempotency या स्थिति क्वेरी का प्रमाण हो।
सामान्य गलतियां और फॉलो-अप
TimeoutError और AbortError को एक समझना
यूज़र अबॉर्ट, अनमाउंट और टाइमआउट के अगले चरण अलग-अलग होते हैं। मैसेजिंग, लॉगिंग और पुनः प्रयास चुनने के लिए कारण के आधार पर वर्गीकृत करें।
यह मान लेना कि क्लाइंट अबॉर्ट सर्वर राइट को रोलबैक कर देता है
रिक्वेस्ट पहले ही सर्वर तक पहुंच चुकी हो सकती है। राइट्स के लिए एक idempotency की, स्टेटस क्वेरी या कंपेंसेशन फ्लो की आवश्यकता होती है।
वास्तविक कैंसलेशन को Promise.race से बदलना
रेस करने से वह बदल जाता है जिसका कॉलर इंतज़ार करता है, लेकिन यह अंतर्निहित fetch को नहीं रोकता है। AbortSignal पास करें और संसाधनों को साफ़ करें।
bfcache के संदर्भ में एक्टिव टाइम की अनदेखी करना
पेज निलंबित होने पर टाइमआउट रुक सकता है। रीस्टोर के बाद की अवधि को ऑनलाइन रिक्वेस्ट SLA के रूप में न मानें।
आप किसी पुराने रिज़ल्ट को जीतने से कैसे रोकते हैं?
पुराने कंट्रोलर को अबॉर्ट करना ही पर्याप्त नहीं है। कमिट करने से पहले क्वेरी सीक्वेंस, वर्जन या वर्तमान क्वेरी की तुलना करें ताकि रिस्पॉन्स का क्रम स्थिति को न बदल सके।