क्यों 2019 में अपना रिएक्ट डेटा ग्रिड लिखें

नमस्कार, हेब्र! मैं एक ईसीएम प्रणाली के विकास में शामिल हूं। और लेखों की एक छोटी श्रृंखला में मैं अपने अनुभव और अपने रिएक्ट डेटा ग्रिड के विकास के इतिहास को साझा करना चाहता हूं (इसके बाद बस एक ग्रिड), अर्थात्:

• हमने तैयार घटकों को क्यों छोड़ दिया
• अपना ग्रिड विकसित करते समय हमने किन समस्याओं और कार्यों का सामना किया
• आपके ग्रिड को क्या लाभ मिलता है

प्रागितिहास

हमारे सिस्टम में एक वेब एप्लिकेशन है जिसमें उपयोगकर्ता दस्तावेजों की सूची, खोज परिणाम, निर्देशिकाओं के साथ काम करते हैं। इसके अलावा, सूचियाँ या तो छोटी (10 कर्मचारी) या बहुत बड़ी (50,000 ठेकेदार) हो सकती हैं। इन सूचियों को प्रदर्शित करने के लिए, हमने अपना ग्रिड विकसित किया:

जब हमने एक वेब एप्लिकेशन विकसित करना शुरू किया, तो हम ग्रिड को प्रदर्शित करने के लिए एक तैयार पुस्तकालय ढूंढना चाहते थे जो हमारे लिए आवश्यक सब कुछ कर सके: सॉर्ट और ग्रुप रिकॉर्ड, ड्रैग एंड ड्रॉप कॉलम, मल्टीपल सिलेक्शन के साथ काम करना, कॉलम योग, फिल्टर और गणना करना सर्वर से डेटा डाउनलोड करें और दसियों हजारों रिकॉर्ड प्रदर्शित करें।

मैं आखिरी आवश्यकता को समझाऊंगा "दसियों हजार रिकॉर्ड प्रदर्शित करें।" ग्रिड में, इस आवश्यकता को कई तरीकों से लागू किया जाता है: पेजिंग, इन्फिनिटी स्क्रॉलिंग, वर्चुअल स्क्रॉलिंग।

पेजिंग और अनंत स्क्रॉल दृष्टिकोण वेबसाइटों पर आम हैं, आप हर दिन उनका उपयोग करते हैं। उदाहरण के लिए, Google में पेजिंग:

या चित्रों पर उसी Google में अनंत स्क्रॉल करना, जहां चित्रों का अगला भाग लोड होता है जब आप पहले भाग से अंत तक स्क्रॉल करते हैं:

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

हमारे वेब एप्लिकेशन के लिए, मैं वर्चुअल स्क्रॉलिंग का उपयोग करना चाहता था। मैं इस बात से सहमत हूं कि 10,000 प्रविष्टियों की सूची में किसी भी स्थान पर स्क्रॉल करना एक बल्कि आविष्कार किया गया मामला है। हालाँकि, 500-1000 के रिकॉर्ड के भीतर रैंडम स्क्रॉलिंग एक जीवंत मामला है।

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

आवश्यकताओं पर वापस। हमें और क्या चाहिए:

• वर्चुअल स्क्रॉलिंग मैनेजमेंट एपीआई
• ग्रिड (पंक्तियों, स्तंभों, संदर्भ मेनू) की उपस्थिति का अनुकूलन ताकि ग्रिड हमारे आवेदन में विदेशी न दिखे
• हमारे द्वारा उपयोग की जाने वाली तकनीकों के लिए समर्थन: प्रतिक्रिया, Redux और flexbox
• ग्रिड 11 में काम किया

सामान्य तौर पर, कई आवश्यकताएं थीं।

पहला प्रयास (2016)। DevExtreme जावास्क्रिप्ट डेटा ग्रिड

मौजूदा पुस्तकालयों की खोज में लंबे समय तक नहीं, हम DevExtreme जावास्क्रिप्ट डेटा ग्रिड पर ठोकर खाई। कार्यात्मक आवश्यकताओं द्वारा, इस ग्रिड ने हमारी सभी आवश्यकताओं को कवर किया और एक बहुत ही प्रस्तुत करने योग्य उपस्थिति थी। हालांकि, यह तकनीकी आवश्यकताओं के लिए उपयुक्त नहीं था (न ही प्रतिक्रिया, न ही रिडक्स, न ही फ्लेक्सबॉक्स)। उस समय, DevExtreme में प्रतिक्रिया ग्रिड नहीं था।

खैर, इसे प्रतिक्रिया न दें, हमने फैसला किया, क्योंकि ग्रिड सुंदर और कार्यात्मक है, हम इसका उपयोग करेंगे। और उन्होंने अपने प्रोजेक्ट में लाइब्रेरी को जोड़ा। यह पता चला कि हमने 3 एमबी स्क्रिप्ट जोड़ी हैं।

कुछ हफ़्ते के लिए, हमने अपने वेब एप्लिकेशन में ग्रिड को एकीकृत किया और बुनियादी कार्यक्षमता बढ़ाई:

• प्रतिक्रिया और रिडक्स के साथ दोस्त बनाने के लिए एक ग्रिड लपेटा
• हमारे वेब सर्वर से वर्चुअल स्क्रॉलिंग और डेटा के भाग लोडिंग को उठाया
• छँटाई और चयन को लागू किया

ग्रिड को खराब करने की प्रक्रिया में, दो गंभीर समस्याएं स्पष्ट हो गईं और कम गंभीर लोगों का एक पूरा झुंड।

पहली गंभीर समस्या

DevExtreme JavaScript Data ग्रिड को Redux के साथ बनाना बहुत मुश्किल है। हम कॉलम सेटिंग्स को नियंत्रित करने और रिकॉर्ड्स को हाइलाइट करने के लिए प्रबंधित करने में कामयाब रहे, लेकिन रेडएक्स में अंश-लोड किए गए डेटा को स्टोर करने के लिए, और रेड्यूड के माध्यम से उन पर सीआरयूडी संचालन करते हैं - यह अवास्तविक है। मुझे एक बैसाखी बनानी पड़ी, जिसने रेडक्स को दरकिनार कर, ग्रिड डेटा में हेरफेर किया। बैसाखी जटिल और नाजुक हो गई। यह पहली अलार्म घंटी थी जो ग्रिड ने हमें सूट नहीं की, लेकिन हमने इसे जारी रखा।

दूसरी गंभीर समस्या

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

कम गंभीर समस्याएं

कम गंभीर समस्याएं हर समय सामने आती हैं, क्योंकि मानक डेवक्स्ट्रीम जावास्क्रिप्ट डेटा ग्रिड कार्यक्षमता हमारे लिए पूरी तरह से उपयुक्त नहीं थी, और हमने इसे सही करने की कोशिश की:

1. ऊंचाई में DevExtreme ग्रिड खींचना काम नहीं करता है। मुझे यह करने के लिए DevExtreme सिखाने के लिए एक हैक लिखना था (शायद हाल के संस्करणों में इसके साथ कोई समस्या नहीं है)।
2. जब फोकस ग्रिड में नहीं होता है, तो कीबोर्ड के माध्यम से लाइनों के चयन को नियंत्रित करना असंभव है (और हमें इसकी आवश्यकता थी)। मुझे अपना कीबोर्ड कंट्रोल लिखना था।
3. जब कॉलम की संरचना बदल रही है और डेटा बदल रहा है, तो हमें ब्लिंकिंग डेटा (वर्चुअल स्क्रॉलिंग सक्षम होने के साथ) की समस्या थी।
4. ग्रिड के पहले प्रदर्शन में बड़ी संख्या में अनुरोधों की समस्या। यह विशेष रूप से ध्यान देने योग्य था जब हमने आंतरिक एपीआई के माध्यम से स्क्रॉलिंग को नियंत्रित किया।
5. UI ग्रिड के कुछ हिस्सों को कस्टमाइज़ करना कठिन है। उदाहरण के लिए, लाइन प्रबंधन क्रियाओं को हटाने के लिए चयनित ग्रिड लाइन के ऊपर एक इच्छा थी (एक लाइन को हटाएं, कॉपी करें, एक कार्ड खोलें)। लेकिन यह कैसे DevExtreme में पेंच के लिए स्पष्ट नहीं था, और यहां तक ​​कि प्रतिक्रिया का उपयोग कर:
   
6. सॉर्टिंग को कैटोमाइज़ करना मुश्किल है (हम ऐसे डेटा के आधार पर छांटना चाहते हैं जो ग्रिड में प्रदर्शित नहीं होते हैं और कॉलम में मैप नहीं किए जाते हैं)।
7. ग्रिड कोशिकाओं में प्रतिक्रिया घटक को पेंच करने के लिए आवश्यक हैं (आखिरकार, ग्रिड प्रतिक्रिया पर नहीं है)।
8. DevExtreme कोड (प्रवाह / टाइपस्क्रिप्ट) की कोई टाइपिंग नहीं।
9. लंबे वर्चुअल स्क्रॉलिंग के साथ स्पीड की समस्या।
10. स्ट्रेचिंग / रिस्ट्रैन्जिंग कॉलम (लंबे समय तक वर्चुअल स्क्रॉलिंग के बाद) में स्पीड की समस्या।
11. ग्रिड स्क्रिप्ट का आकार 3 एमबी है।

हालाँकि DevExtreme कार्यक्षमता ग्रिड में वह सब कुछ था जो हमें चाहिए था, लेकिन मैं लगभग सभी मानक कार्यक्षमता को फिर से लिखना चाहता था। इसके उपयोग के दौरान, कोड की सैकड़ों पंक्तियों को समझना मुश्किल था, जो कि redux और प्रतिक्रिया के साथ इंटरैक्ट करने की समस्याओं को हल करने का प्रयास करती थी, एक प्रतिक्रिया एप्लिकेशन में गैर-प्रतिक्रिया ग्रिड का उपयोग करना मुश्किल था।

DevExtreme के इनकार। विकल्प की तलाश करें

कुछ समय बाद DevExtreme का उपयोग करते हुए, इसे छोड़ने का निर्णय लिया गया। सभी हैक्स, कॉम्प्लेक्स कोड, साथ ही 3 एमबी ऑफ डेवक्लेर स्क्रिप्ट को फेंक दें। और एक नया ग्रिड खोजें या लिखें।

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

प्रौद्योगिकी आवश्यकताएँ:

• प्रतिक्रिया
• redux
• flexbox

कार्यात्मक आवश्यकताएँ:

• वर्चुअल स्क्रॉलिंग (दसियों हजारों रिकॉर्ड प्रदर्शित करने की क्षमता के साथ)
• स्क्रॉलिंग प्रबंधन एपीआई
• रिडक्स में डेटा और ग्रिड सेटिंग्स को स्टोर करना
• वेब सर्वर से बैच लोडिंग डेटा
• स्तंभ प्रबंधन (खिंचाव / पुनर्व्यवस्थित / दृश्यता नियंत्रण)
• कॉलम छँटाई + छानने
• एकाधिक चयन
• जैसे- बैकलाइट के साथ सर्च करना
• क्षैतिज स्क्रॉलिंग
• कीबोर्ड के साथ कार्य करना
• संदर्भ मेनू (एक पंक्ति पर, खाली क्षेत्र पर, स्तंभों पर)
• समर्थन ie11, बढ़त, क्रोम, एफएफ, सफारी

इस बिंदु पर, DevExtreme React Grid का पहला संस्करण पहले ही सामने आ चुका था, लेकिन हमने तुरंत इसे निम्न कारणों के लिए छोड़ दिया:

• Virtual स्क्रॉलिंग का समर्थन ie11 में नहीं किया गया है
• वर्चुअल स्क्रॉलिंग सर्वर से डेटा डाउनलोड करने के बैच के साथ काम नहीं करता है (हालांकि कुछ वर्कअराउंड लगते हैं)।
• और सबसे महत्वपूर्ण बात, मैं एक ही रेक पर कदम नहीं रखना चाहता था जब मैं किसी तीसरे पक्ष के ग्रिड की आधी मानक कार्यक्षमता को फिर से लिखना चाहता था।

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

अपने रिएक्ट डेटा ग्रिड का विकास करना

ग्रिड का विकास प्रोटोटाइप के साथ शुरू हुआ, जहां उन्होंने हमारे लिए सबसे कठिन विषयों का परीक्षण किया:

• आभासी स्क्रॉल
• Redux में सभी ग्रिड डेटा का भंडारण

वर्चुअल स्क्रॉलिंग

वर्चुअल स्क्रॉलिंग में सबसे मुश्किल निकला। अधिकांश भाग के लिए, इसे 3 तरीकों में से एक में बनाया गया है:

1. पृष्ठ का औचित्य
डेटा भागों में खींचा जाता है - पृष्ठ। स्क्रॉल करते समय, दृश्यमान पृष्ठ जोड़े जाते हैं, अदृश्य हटा दिए जाते हैं। पृष्ठ में 20-60 पंक्तियाँ होती हैं (आमतौर पर आकार अनुकूलन योग्य होता है)। यह वह जगह है जहां उत्पाद गए: डेक्स्ट्रीम जावास्क्रिप्ट डेटा ग्रिड, एमएस फैब्रिक विवरण।

2. लाइन-बाय-लाइन वर्चुअलाइजेशन
केवल दृश्य रेखाएँ खींची जाती हैं। जैसे ही एक लाइन स्क्रीन छोड़ती है, उसे तुरंत हटा दिया जाता है। उत्पादों को इस तरह से चला गया: ReactVirtualized ग्रिड, DevExtreme रिएक्ट ग्रिड, टेलरिक ग्रिड।

3. कैनवास
सभी लाइनें और उनकी सामग्री कैनवस का उपयोग करके तैयार की गई हैं। Google डॉक्स ने यही किया है।

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

अन्य विकल्पों को क्यों छोड़ दिया?

लाइन-बाय-लाइन वर्चुअलाइजेशन में प्रोटोटाइप में गति प्रदान करने की समस्याएं थीं। जैसे ही लाइनों की सामग्री अधिक जटिल हो गई (बहुत अधिक पाठ, हाइलाइटिंग, ट्रिमिंग, आइकन, बड़ी संख्या में कॉलम और हर जगह फ्लेक्सबॉक्स), प्रति सेकंड कई बार लाइनों को जोड़ना / निकालना महंगा हो गया। बेशक, परिणाम ब्राउज़र पर भी निर्भर करते हैं (हमने समर्थन का समर्थन किया है, जैसे कि ie11, एज):

कैनवस विकल्प गति प्रदान करने में बहुत मोहक था, लेकिन श्रमसाध्य। यह सब कुछ आकर्षित करने का प्रस्ताव था: पाठ, पाठ रैपिंग, पाठ ट्रिमिंग, हाइलाइटिंग, आइकन, विभाजन रेखाएं, हाइलाइटिंग, इंडेंटेशन। जब आप पर मंडराते हैं, तो लाइनों को हाइलाइट करते हुए, कैनवस पर माउस बटन पर क्लिक करने के लिए एक प्रतिक्रिया करें। उसी समय, कुछ डोम तत्वों (संकेत दिखाते हुए, लाइन पर "पॉप-अप एक्शन") को कैनवस पर लागू किया जाना चाहिए। कैनवस में धुंधला पाठ और आइकन की समस्या को हल करना अभी भी आवश्यक था। यह सब करना लंबा और कठिन है। हालांकि हमने प्रोटोटाइप में महारत हासिल की। उसी समय, भविष्य में पंक्तियों और कोशिकाओं के किसी भी अनुकूलन के परिणामस्वरूप हमारे लिए एक बड़ी श्रमसाध्यता होगी।

पेजिंग के लाभ

लाइन-बाय-लाइन की तुलना में चयनित पृष्ठ-दर-पृष्ठ वर्चुअलाइजेशन के फायदे थे, जिसने इसकी पसंद निर्धारित की:

• यदि पृष्ठ पहले से ही गाया हुआ है, तो पृष्ठ के अंदर स्क्रॉल करना सस्ता है (स्क्रॉल करते समय DOM ट्री नहीं बदलता है)। किसी भी मामूली स्क्रॉलिंग के साथ लाइन-बाय-लाइन वर्चुअलाइजेशन के लिए DOM ट्री को बदलने की आवश्यकता होती है, और यह तब महंगा होता है जब DOM ट्री जटिल होता है और फ्लेक्सबॉक्स हर जगह उपयोग किया जाता है।
• छोटी सूचियों के लिए (<200 प्रविष्टियाँ) पृष्ठ हटाए नहीं जा सकते, बस जोड़ें। जल्दी या बाद में, सभी पृष्ठ बनाए जाएंगे, और स्क्रॉलिंग पूरी तरह से मुफ्त होगी (समय प्रदान करने के संदर्भ में)।

पृष्ठ आकार चयन

एक अलग मुद्दा पृष्ठ आकार का विकल्प है। मैंने ऊपर लिखा है कि आकार अनुकूलन योग्य है और आमतौर पर 20-60 लाइनें हैं। एक बड़े पृष्ठ को लंबे समय तक खींचा जाता है, एक छोटा एक स्क्रॉल करते समय "सफेद स्क्रीन" के लगातार प्रदर्शन की ओर जाता है। प्रयोगात्मक रूप से, 25 लाइनों का एक पृष्ठ आकार चुना गया था। हालाँकि, ie11 के लिए आकार को 5 लाइनों तक घटा दिया गया है। IE में इंटरफ़ेस की तरह लगता है यदि आप एक बड़े विलंब के साथ एक से एक छोटे से देरी के साथ बहुत सारे छोटे पृष्ठ खींचते हैं, तो यह अधिक उत्तरदायी है।

रिएक्ट और वर्चुअल स्क्रॉलिंग

प्रतिक्रिया का उपयोग करके पृष्ठ वर्चुअलाइजेशन को लागू किया जाना था। ऐसा करने के लिए, कई कार्यों को हल किया जाना चाहिए:

कार्य 1. स्क्रॉल करते समय प्रतिक्रिया के माध्यम से पृष्ठों को कैसे जोड़ें / निकालें?

इस समस्या को हल करने के लिए, निम्नलिखित अवधारणाएं पेश की गईं:

• पेज मॉडल
• पृष्ठ दृश्य

एक मॉडल एक जानकारी है जिस पर एक दृश्य बनाना है। एक दृश्य एक प्रतिक्रिया घटक है।

वास्तव में, इसके बाद वर्चुअलाइजेशन का कार्य पेज मॉडल में हेरफेर करने के लिए नीचे आया था: स्क्रॉल करते समय मॉडल को जोड़ने, हटाने और पृष्ठ मॉडल की एक सूची संग्रहीत करें। और पहले से ही प्रतिक्रिया के माध्यम से मॉडल की सूची से प्रदर्शन का निर्माण / पुनर्निर्माण:

कार्यान्वयन के दौरान, पेज मॉडल के साथ काम करने के नियम बनाए गए थे:

• पृष्ठों को एक समय में एक जोड़ा जाना चाहिए। प्रत्येक जोड़ के बाद, आकर्षित करने के लिए समय दें। प्रत्येक 300-500ms में 1 पृष्ठ जोड़ना स्वीकार्य है - यह एक तेज़ स्क्रॉलिंग स्थिति है। यदि आप उदाहरण के लिए, एक साथ 5 पृष्ठ जोड़ते हैं, तो उपयोगकर्ता का इंटरफ़ेस उनके निर्माण पर लटका हुआ है।
• पृष्ठों को दसियों में रखने की आवश्यकता नहीं है। एक समस्या की स्थिति का एक उदाहरण: 20 पृष्ठ प्रदर्शित होते हैं, उपयोगकर्ता दूसरी सूची में जाता है और सभी 20 पृष्ठों को एक बार में हटा दिया जाना चाहिए। बड़ी संख्या में पृष्ठों को हटाना एक महंगा ऑपरेशन है, DOM ट्री को साफ करने में 1 सेकंड लगेगा। इससे बचने के लिए, एक बार में 10 से अधिक पेज न रखना बेहतर है।
• किसी भी कॉलम हेरफेर (पुनर्व्यवस्था, जोड़, विलोपन, स्ट्रेचिंग) के लिए उन पृष्ठों को हटाना बेहतर है जो पहले से उपयोगकर्ता को दिखाई नहीं देते हैं। यह सभी प्रदान किए गए पृष्ठों के महंगे पुनर्निर्माण से बचना होगा।

कार्य 2. स्कॉलर को कैसे प्रदर्शित किया जाए?

वर्चुअल स्क्रॉलिंग मानती है कि एक स्क्रॉलबार उपलब्ध है, जो सूची के आकार को ध्यान में रखता है और आपको कहीं भी स्क्रॉल करने की अनुमति देता है:

ऐसे स्कोलबार को कैसे प्रदर्शित किया जाए? सबसे सरल समाधान वास्तविक डेटा के बजाय आवश्यक आकार का एक अदृश्य div आकर्षित करना है। और पहले से ही इस div के शीर्ष पर हम दृश्यमान पृष्ठ प्रदर्शित करते हैं:

कार्य 3. व्यूपोर्ट के आकार की निगरानी कैसे करें?

व्यूपोर्ट ग्रिड का दृश्यमान डेटा क्षेत्र है। उसके आकार पर नज़र क्यों रखें? उन पृष्ठों की संख्या की गणना करने के लिए जिन्हें उपयोगकर्ता को प्रदर्शित करने की आवश्यकता है। मान लें कि हमारे पास एक छोटा पृष्ठ आकार (5 लाइनें) और एक बड़ा स्क्रीन रिज़ॉल्यूशन (1920x1080) है। संपूर्ण व्यूपोर्ट को बंद करने के लिए उपयोगकर्ता को कितने पृष्ठों की आवश्यकता होती है?

यदि आप व्यूपोर्ट की ऊंचाई और एक पृष्ठ की ऊंचाई जानते हैं, तो आप इस समस्या को हल कर सकते हैं। अब कार्य को जटिल करते हैं, मान लीजिए कि उपयोगकर्ता ब्राउज़र में पैमाने को तेजी से बदलता है - 50% सेट करता है:

पैमाने के साथ स्थिति से पता चलता है कि व्यूपोर्ट के आकार को एक बार पता लगाने के लिए पर्याप्त नहीं है, आपको आकार की निगरानी करने की आवश्यकता है। और अब हम कार्य को पूरी तरह से जटिल कर देंगे: HTML तत्वों में एक आकार परिवर्तन घटना नहीं है, जिसे आप सदस्यता ले सकते हैं और आकार की निगरानी कर सकते हैं। केवल विंडो ऑब्जेक्ट का आकार बदल गया है।

पहली बात जो मन में आती है वह है टाइमर का उपयोग करना और html तत्व की ऊंचाई को लगातार प्रदूषित करना। लेकिन एक और भी बेहतर समाधान है जिसे हमने डेवक्स्ट्रीम जावास्क्रिप्ट डेटा ग्रिड के साथ देखा: एक अदृश्य आइफ्रेम बनाएं, इसे ग्रिड आकार में फैलाएं और iframe.contentWindow के आकार बदलने वाले इवेंट की सदस्यता लें:

सारांश

PS यह अंत नहीं है। अगले लेख में मैं बताऊंगा कि कैसे हमने redux के साथ दोस्ती की।

पूर्ण वर्चुअल स्क्रॉलिंग प्राप्त करने के लिए, कई अन्य कार्यों को हल करना पड़ा। लेकिन ऊपर वर्णित वे सबसे दिलचस्प थे। यहाँ कुछ अन्य कार्य हैं जो पॉप अप भी करते हैं:

• पृष्ठों को जोड़ते / निकालते समय स्क्रॉलिंग की दिशा और गति को ध्यान में रखें।
• पेज मॉडल के पुनर्निर्माण को कम करने के लिए डेटा परिवर्तनों को ध्यान में रखें। उदाहरण के लिए, एक पंक्ति को हटा दिया गया, या एक पंक्ति जोड़ दी गई, पहले से ही प्रदान किए गए पृष्ठों के साथ क्या करना है? सब कुछ फेंक दो, या कुछ छोड़ दो? अनुकूलन के लिए जगह है।
• चयन बदलते समय, न्यूनतम आवश्यक पृष्ठों की संख्या पुनः व्यवस्थित करें।

यदि आपके पास कार्यान्वयन के बारे में प्रश्न हैं, तो आप उन्हें टिप्पणियों में लिख सकते हैं।