बड़ी सूची को Render करने की समस्या

मान लीजिए कि आप दस हज़ार आइटम वाली एक सारणी पर मैप करके हर आइटम के लिए एक सूची-तत्व रेंडर करते हैं। रिएक्ट हर बार दस हज़ार DOM नोड बनाएगा, भले ही एक समय में स्क्रीन पर केवल दो-तीन दर्जन ही दिखाई देते हों।

इनमें से अधिकांश नोड स्क्रीन से बाहर और अदृश्य होते हैं, फिर भी ब्राउज़र को उनमें से हर एक को बनाना, उसका लेआउट तय करना और बनाए रखना पड़ता है।

बड़े DOM वृक्षों की ब्राउज़र में वास्तविक लागत होती है। लेआउट, शैली की पुनर्गणना और मेमोरी, सभी नोडों की संख्या के साथ बढ़ते हैं, इसलिए बहुत बड़ी सूची आरंभिक रेंडर को धीमा करती है और मेमोरी का उपयोग बढ़ाती है।

जब इंजन को हज़ारों नोडों पर नज़र रखकर उनका पुनःप्रवाह करना पड़ता है, तब साधारण इंटरैक्शन भी रुक-रुककर चल सकते हैं।

बहुत बड़ी सूची को स्क्रॉल करते समय उपयोगकर्ताओं को समस्या सबसे अधिक महसूस होती है। सामग्री के खिसकने पर ब्राउज़र उसे फिर से पेंट करता है और लेआउट की दोबारा गणना कर सकता है; बहुत अधिक नोड होने पर फ़्रेम दर सहज गति से नीचे गिर जाती है।

इसका परिणाम झटकेदार और धीमा स्क्रॉल होता है, जिससे ऐप का बाकी हिस्सा कितना भी तेज़ क्यों न हो, इंटरफ़ेस अनुत्तरदायी महसूस होता है।

आप ब्राउज़र के DevTools मेमोरी पैनल में इस समस्या की पुष्टि कर सकते हैं, जहाँ पृष्ठ पर मौजूद DOM नोडों की संख्या दिखाई जाती है। हज़ारों नोड बनाने वाली सूची यहाँ स्पष्ट रूप से दिखाई देगी।

अधिक आइटम रेंडर करने पर इस संख्या को तेज़ी से बढ़ते देखना ठोस प्रमाण देता है कि अड़चन DOM का आकार है।

वर्चुअलाइज़ेशन, जिसे कभी-कभी विंडोइंग भी कहा जाता है, पूरी सूची के बजाय केवल वर्तमान में दिखाई देने वाले आइटम और एक छोटे बफ़र को रेंडर करता है। स्क्रॉल करते समय दिखाई देने वाले आइटम माउंट किए जाते हैं और दृश्य से बाहर जाने वाले आइटम अनमाउंट किए जाते हैं।

इससे डेटा में कितने भी आइटम हों, सक्रिय DOM छोटा रहता है और DOM का आकार डेटा-समूह के आकार से स्वतंत्र हो जाता है।

दृश्य विंडो स्क्रॉल की स्थिति, कंटेनर की ऊँचाई और आइटम की ऊँचाई से निकाली जाती है। व्यूपोर्ट की ऊँचाई को आइटम की ऊँचाई से भाग देने पर लगभग पता चलता है कि कितनी पंक्तियाँ समा सकती हैं, और स्क्रॉल ऑफ़सेट बताता है कि वे कौन-सी पंक्तियाँ हैं।

लाइब्रेरी इन संख्याओं का उपयोग यह तय करने के लिए करती है कि किसी भी क्षण आइटम का कौन-सा स्लाइस रेंडर किया जाए।

कई लाइब्रेरी विंडोइंग लागू करती हैं। रिएक्ट-वर्चुअलाइज़्ड सुविधाओं से भरपूर, लेकिन बड़ी है; रिएक्ट-विंडो उसी लेखक द्वारा किया गया छोटा और केंद्रित पुनर्लेखन है; और TanStack वर्चुअल एक आधुनिक हेडलेस विकल्प है।

अधिकांश सूचियों के लिए रिएक्ट-विंडो सरलता और प्रदर्शन का उत्कृष्ट संतुलन देता है, इसलिए यह पाठ्यक्रम इसी पर केंद्रित है।

जब सूचियाँ लंबी हों—लगभग कई सौ पंक्तियाँ या उससे अधिक—या पंक्तियों में चित्र और नेस्टेड कंपोनेंट अधिक हों, तब वर्चुअलाइज़ेशन लाभ देता है। इन्हीं स्थितियों में DOM का आकार वास्तव में प्रदर्शन को प्रभावित करता है।

अनंत फ़ीड, बड़ी डेटा सारणियाँ और चैट इतिहास ऐसे सामान्य उदाहरण हैं जहाँ विंडोइंग वैकल्पिक न रहकर आवश्यक हो जाती है।

कुछ दर्जन साधारण आइटम वाली छोटी सूचियों के लिए वर्चुअलाइज़ेशन बिना किसी महत्वपूर्ण लाभ के जटिलता बढ़ाता है। निरपेक्ष स्थिति निर्धारण और मापन की अतिरिक्त लागत से कुल प्रदर्शन और भी खराब हो सकता है।

विंडोइंग को वास्तव में बड़े डेटा-समूहों के लिए रखें; छोटे डेटा-समूहों के लिए साधारण मैप अधिक सरल और पूरी तरह तेज़ है।

विंडोइंग के साथ एक लाख आइटम वाली सूची में DOM के अंदर केवल स्क्रीन पर दिखाई देने वाले कुछ आइटम रहते हैं। इसलिए आरंभिक रेंडर तेज़ होता है, मेमोरी का उपयोग कम रहता है और स्क्रॉल सहज होता है।

आप सेटअप में थोड़ी जटिलता के बदले ऐसा प्रदर्शन पाते हैं जो आपके पास मौजूद डेटा की मात्रा पर निर्भर नहीं करता—यही वर्चुअलाइज़ेशन का मुख्य वादा है।

हज़ारों DOM नोड रेंडर करने से लेआउट की लागत, मेमोरी का उपयोग और स्क्रॉल में झटके बढ़ते हैं। DevTools में नोडों की संख्या देखकर इसकी पुष्टि की जा सकती है। वर्चुअलाइज़ेशन केवल दृश्य विंडो और एक बफ़र को रेंडर करता है, जिससे DOM छोटा रहता है।

रिएक्ट-विंडो, रिएक्ट-वर्चुअलाइज़्ड और TanStack वर्चुअल में एक केंद्रित और हल्का विकल्प है। इसका उपयोग बड़ी या भारी सूचियों के लिए करें और छोटी, सरल सूचियों के लिए इसे छोड़ दें।