Enterprise: ड्रॉपडाउन/बहु-चयन: एक चयन तत्व के विपरीत डेटा स्रोत ऑब्जेक्ट का उपयोग करने के लिए रिफैक्टर

नोट: यह समस्या संभावित रूप से #843 (और अन्य) में पहचानी गई कुछ प्रदर्शन समस्याओं का समाधान करती है।

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

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

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 नवीनतम है

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

आप जो समाधान चाहते हैं उसका वर्णन करें
ड्रॉपडाउन/मल्टीसेलेक्ट के प्रदर्शन को ठीक करने के लिए एक संभावित समाधान पथ:

• [ ] प्राथमिक डेटा स्रोत के रूप में <select> का उपयोग करने की एक कठिन आवश्यकता। #267 से कुछ हालिया सुधारों ने यह पता लगाना शुरू किया कि कैसे एक AJAX कॉल ड्रॉपडाउन के लिए एक डेटा ऑब्जेक्ट उत्पन्न कर सकता है जिसे हम क्लाइंट पर स्टोर कर सकते हैं। मुझे लगता है कि हमें इस जानकारी को डीओएम तत्व से हथियाने के बजाय घटक के व्यवहार के प्राथमिक चालक के रूप में कुछ साधारण राज्यों (अक्षम/चयनित/आदि) के साथ ऑब्जेक्ट का उपयोग करने की ओर बढ़ना चाहिए। <select> टैग और उसके <option> s का प्रतिपादन अभी भी फॉर्म जमा करने जैसी चीजों के लिए आवश्यक होगा, लेकिन हमें डेटा ऑब्जेक्ट को "सत्य के स्रोत" के रूप में परिभाषित करना चाहिए, और चयन टैग को ड्रा करना चाहिए वस्तु के आधार पर (इसके विपरीत नहीं)।
• [ ] यह भी एक्सप्लोर करें कि किसी भी अर्थ में <select> टैग पर निर्भरता नहीं है / नहीं है। यह एक डेवलपर के लिए ड्रॉपडाउन/मल्टीसेलेक्ट का उपयोग करने के लिए एक उचित उपयोग का मामला हो सकता है, जिसमें फॉर्म जमा करने के अनुरोध को आसानी से रोकने के लिए और सामान्य फॉर्म सबमिशन प्रक्रिया पर भरोसा करने के बजाय डेटासोर्स ऑब्जेक्ट की स्थिति भेजने के लिए कई आइटम हैं। वर्तमान में, इस प्रकार का उपयोग संभव नहीं है।
• [ ] एक बार जब हम DOM तत्व पर भरोसा नहीं करते हैं, तो हम किसी भी समय DOM में केवल सूची आइटम्स का एक सबसेट प्रदर्शित करना शुरू कर सकते हैं। चूंकि राज्य को डेटासोर्स ऑब्जेक्ट द्वारा बनाए रखा जाता है, इसलिए डोम जरूरी नहीं है, और सूची आइटम की छोटी मात्रा को लोड/अनलोड करने के लिए यह अधिक छोटा होना चाहिए क्योंकि उपयोगकर्ता सूची के माध्यम से स्क्रॉल करता है (हमें # 460 का पता लगाने की अनुमति देगा ड्रॉप डाउन)।
• [ ] बड़े डेटासेट के सर्वर-साइड हैंडलिंग के लिए बेहतर अनुशंसाएं बनाएं। क्लाइंट-साइड ऑब्जेक्ट में राज्य को बनाए रखने के साथ-साथ कई रिकॉर्ड अंततः बहुत धीमे हो सकते हैं। हम सर्वर पर ड्रॉपडाउन/मल्टीसेलेक्ट रिकॉर्ड को संभालने के लिए आईडीएस के कार्यान्वयन को कैसे चाहते हैं, इसके बारे में एक सिफारिश और/या कुछ डेमो चाहते हैं।

उन विकल्पों का वर्णन करें जिन पर आपने विचार किया है
कुछ अन्य विचार जो हमने अतीत में बनाए हैं:

• एक सरल घटक जो <select> टैग्स को ओवरले करता है और इंटरैक्शन के लिए छद्म मार्कअप उत्पन्न करने के बजाय उन्हें स्टाइल करता है। यह बड़ी सूची को बेहतर ढंग से संभालने में सक्षम हो सकता है क्योंकि यह इसकी नकल नहीं करेगा। इस मामले में हमें अभी भी 2000ish तत्वों को एक बार में संभालना होगा।