प्रॉम्प्ट और संदर्भ
यह फ्रंटेंड प्रश्न लॉन्ग-लिस्ट इंटरैक्शन स्टेट, नेटवर्क सीमाओं और एक्सेसिबिलिटी का परीक्षण करता है। चुनौती केवल एक ऑब्ज़र्वर को सेंटिनल से जोड़ना नहीं है; बल्कि लोडिंग, कैंसिलेशन, विफलता, पुनः प्रयास (retry), पोज़ीशन रिस्टोरेशन और वैकल्पिक नेविगेशन के लिए एक पूर्ण अनुबंध (contract) को परिभाषित करना है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप Intersection Observer या इसके समकक्ष मैकेनिज़्म से लोडिंग ट्रिगर कर सकते हैं और प्रीफेच दूरी को ट्यून कर सकते हैं।
- क्या कर्सर स्टेट, रिक्वेस्ट डुप्लीकेशन की रोकथाम और क्रमबद्धता डुप्लीकेट पेजों, आउट-ऑफ़-ऑर्डर पेजों और अंतहीन पुनः प्रयासों को रोकते हैं।
- क्या कीबोर्ड, स्क्रीन-रीडर, ज़ूम और धीमे नेटवर्क वाले यूज़र्स को दृश्यमान और ऑपरेट करने योग्य स्टेट्स मिलती हैं।
- क्या आप यह पहचानते हैं कि इनफिनिट स्क्रॉल को पेजिनेशन, स्किप-टू-कंटेंट पाथ या पोज़ीशन रिस्टोरेशन की आवश्यकता कब होती है।
पूछने के लिए स्पष्टीकरण प्रश्न
पुष्टि करें कि क्या लिस्ट एक टाइमलाइन, सर्च रिज़ल्ट या ग्रिड है; क्या क्रमबद्धता स्थिर है; क्या सर्वर कर्सर जारी कर सकता है; और पेज का आकार व फ़र्स्ट-कंटेंट टारगेट क्या है। डीप लिंक्स, बैक-नेविगेशन रिस्टोरेशन, बदलती कंटेंट ऊंचाइयों और मोबाइल डेटा सीमाओं के बारे में पूछें।
30-सेकंड उत्तर रूपरेखा
मैं स्थिर कर्सर पेजिनेशन और एक हटाने योग्य लोडिंग सेंटिनल का उपयोग करूंगा। केवल तभी लोड करें जब कोई रिक्वेस्ट एक्टिव न हो, दूसरा कर्सर मौजूद हो, और सेंटिनल प्रीफेच विंडो में प्रवेश करे; क्रम को बनाए रखते हुए कर्सर और आइटम id द्वारा डुप्लीकेट्स हटाएं। लोडिंग, विफलता, पुनः प्रयास और लिस्ट-के-अंत की स्टेट्स फ़ोकस करने योग्य और दृश्यमान होती हैं। मैं एक स्पष्ट पेजिनेशन या "Load more" पाथ, स्किप-टू-कंटेंट और पोज़ीशन रिस्टोरेशन भी प्रदान करूंगा ताकि केवल स्क्रॉलिंग ही नेविगेशन का एकमात्र तरीका न रहे।
चरण-दर-चरण विस्तृत विश्लेषण
1. डेटा और पोज़ीशन अनुबंध को परिभाषित करें
ऐसे कर्सर को प्राथमिकता दें जो नए रिकॉर्ड्स द्वारा विस्थापित न हो। अगला कर्सर और स्थिर आइटम ids लौटाएं। ज्ञात कर्सर, देखे गए ids और रिक्वेस्ट स्टेट को क्लाइंट पर रखें ताकि किसी इंसर्शन के बाद पेज नंबर आइटमों को डुप्लीकेट या स्किप न करें। नेविगेशन से दूर जाने पर, रूट, कर्सर और एंकर ऑफ़सेट रिकॉर्ड करें; डेटा तैयार होने पर दृश्यमान आइटम को पुनर्स्थापित करें।
2. ट्रिगरिंग और कॉनकरेंसी नियंत्रण डिज़ाइन करें
Intersection Observer "नीचे के करीब" होने का संकेत देता है; यह असीमित फ़ेचिंग को अधिकृत नहीं करता है। लोड करने से पहले, hasNext, loading, पुनः प्रयास बजट और नेटवर्क स्थिति की जांच करें। प्रति कर्सर एक रिक्वेस्ट की अनुमति दें। आइटम की ऊंचाई और लेटेंसी का उपयोग करके प्रीफेच थ्रेशोल्ड को ट्यून करें, और तेज़ स्क्रॉलिंग के लिए एक स्पष्ट बटन रखें ताकि बार-बार होने वाले ऑब्ज़र्वर कॉलबैक एक साथ कई रिक्वेस्ट्स की बाढ़ (burst) न बना सकें।
3. रिस्पॉन्स, कैंसिलेशन और विफलता को संभालें
सत्यापित करें कि कोई रिस्पॉन्स अपेक्षित कर्सर से संबंधित है। बिना सोचे-समझे जोड़ने के बजाय देर से आने वाले रिस्पॉन्स को छोड़ दें या ज्ञात सेट में मर्ज कर दें। पेज छोड़ने पर रेंडर किए गए डेटा को हटाए बिना एक एक्टिव रिक्वेस्ट को रद्द किया जा सकता है। एक विफलता स्थिति समस्या की व्याख्या करती है, एक पुनः प्रयास बटन दिखाती है, और लोड किए गए आइटमों की संख्या दर्शाती है। आउटेज के दौरान रिक्वेस्ट्स के तूफ़ान से बचने के लिए स्वचालित पुनः प्रयास सीमित एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं।
4. सुलभ वैकल्पिक पाथ प्रदान करें
सेंटिनल ही एकमात्र कंट्रोल नहीं होना चाहिए। फ़ोकस करने योग्य "Load more", स्पष्ट लोडिंग और लिस्ट-के-अंत की घोषणाएं, सेमेंटिक लिस्ट मार्कअप, स्थिर हेडिंग्स और दृश्यमान फ़ोकस प्रदान करें। लंबी लिस्ट्स में पेजिनेशन, स्किप-डुप्लीकेट्स पाथ और "Back to list top" लिंक दिखाई दे सकते हैं। फ़ोकस मूवमेंट के लिए एक नियम की आवश्यकता है; नए नोड्स डालने से कीबोर्ड यूज़र्स अंत में नहीं पहुँचने चाहिए।
5. परफ़ॉर्मेंस, उपयोगिता और रिकवरी सत्यापित करें
केवल Tab और Enter का उपयोग करके कई पेजों को लोड करने का परीक्षण करें और सत्यापित करें कि एक स्क्रीन रीडर नए कंटेंट और विफलताओं को समझता है। धीमे नेटवर्क, ऑफ़लाइन मोड, तेज़ स्क्रॉलिंग, बार-बार सक्रियण, बैक/फ़ॉरवर्ड नेविगेशन, 200% ज़ूम और डायनामिक इमेज ऊंचाइयों का अभ्यास करें। रिक्वेस्ट संख्या, डुप्लीकेट दर, फ़र्स्ट-पेज और प्रति-पेज लेटेंसी, कैंसिलेशन और रिस्टोरेशन की सफलता को मापें। यदि वर्चुअलाइज़ेशन की आवश्यकता है, तो सत्यापित करें कि यह सेमेंटिक्स और फ़ोकस को बनाए रखता है।
मजबूत नमूना उत्तर
मैं लिस्ट को एक स्थिर कर्सर और आइटम ids पर आधारित करूंगा, जिसमें उपयोग किए गए कर्सर, देखे गए ids, एक्टिव रिक्वेस्ट और पुनः प्रयास संख्या के लिए क्लाइंट स्टेट होगी। सेंटिनल एक प्रीफेच विंडो के अंदर एक लोड सिग्नल भेजता है; रिस्पॉन्स वर्तमान कर्सर से मेल खाना चाहिए, और डुप्लीकेट या क्रम से बाहर के आइटम हटा दिए जाते हैं। विफलता एक फ़ोकस करने योग्य पुनः प्रयास कंट्रोल दिखाती है जबकि ऑफ़लाइन मोड लोड किए गए कंटेंट को बनाए रखता है। इनफिनिट स्क्रॉल के साथ-साथ, मैं "Load more", पेजिनेशन या एक जंप कंट्रोल प्रदान करता हूँ ताकि कीबोर्ड और स्क्रीन-रीडर यूज़र्स स्क्रॉल व्हील पर निर्भर न रहें। बैक नेविगेशन एक आइटम एंकर को पुनर्स्थापित करता है। मैं धीमे और ऑफ़लाइन नेटवर्क, तेज़ स्क्रॉलिंग, ज़ूम, बैक/फ़ॉरवर्ड और एक स्क्रीन रीडर को मान्य करता हूँ।
सामान्य गलतियाँ
- इंसर्शन के बाद डुप्लीकेट्स या छूट जाने वाले आइटमों पर विचार किए बिना पेज नंबर जोड़ना।
- कर्सर डुप्लीकेशन रोकथाम या इन-फ़्लाइट लॉक के बिना प्रत्येक ऑब्ज़र्वर कॉलबैक पर एक रिक्वेस्ट शुरू करना।
- हमेशा पुनः प्रयास करते रहना, या पुनः प्रयास को ऐसे टेक्स्ट के रूप में रेंडर करना जो फ़ोकस प्राप्त नहीं कर सकता।
- स्क्रॉलिंग को एकमात्र नेविगेशन बनाना, जिसमें कोई कीबोर्ड लोडिंग, पेजिनेशन या वापसी का पाथ न हो।
- नए नोड्स आने पर फ़ोकस को अंत में ले जाना, जिससे पाठक की पोज़ीशन खो जाती है।
- केवल तेज़ डेस्कटॉप कनेक्शन पर परीक्षण करना और ऑफ़लाइन मोड, ज़ूम, डायनामिक ऊंचाई व रिस्टोरेशन की अनदेखी करना।
फ़ॉलो-अप प्रश्न और उत्तर
पेज-नंबर पेजिनेशन का उपयोग क्यों न करें?
जब रिकॉर्ड डाले या हटाए जाते हैं, तो पेज की सीमाएं बदल जाती हैं। स्थिर क्रमबद्धता के साथ कर्सर डुप्लीकेट्स और छूटने वाले आइटमों को कम करता है। यदि कोई स्नैपशॉट स्वीकार्य है, तो एक स्नैपशॉट टोकन एक ब्राउज़िंग सीमा को परिभाषित कर सकता है।
बहुत जल्दी ट्रिगर होने वाले सेंटिनल को कैसे ट्यून करते हैं?
औसत आइटम ऊंचाई, स्क्रॉल गति, नेटवर्क लेटेंसी और कैंसिलेशन दर से root margin को ट्यून करें, और इसे मापने योग्य बनाएं। प्रीफेच hasNext, कॉनकरेंसी लॉक और पुनः प्रयास बजट द्वारा सीमित रहता है।
जब नए आइटम शीर्ष पर आते हैं तो पोज़ीशन कैसे सुरक्षित रखते हैं?
एक एंकर आइटम और उसके सापेक्ष ऑफ़सेट को रिकॉर्ड करें, नए नोड्स डालें और स्क्रॉल ऑफ़सेट की भरपाई करें। स्क्रीन-रीडर और कीबोर्ड यूज़र्स के लिए, एक "New items" कंट्रोल दिखाएं ताकि वे चुन सकें कि कब जंप करना है।
डिज़ाइन को पेजिनेटेड कब बनाना चाहिए?
जब डीप लिंक्स, सटीक पेज जंप, परिणामों की तुलना, बहुत लंबी लिस्ट्स या स्पष्ट रीडिंग सेक्शन महत्वपूर्ण हों, तब पेजिनेशन का उपयोग करें। प्रोग्रेसिव लोडिंग रह सकती है, लेकिन एक दृश्यमान पेजिनेशन या "Load more" पाथ मौजूद होना चाहिए।