Enterprise: القائمة المنسدلة / التحديد المتعدد: Refactor لاستخدام كائن مصدر بيانات بدلاً من تحديد عنصر

ملاحظة: من المحتمل أن تتناول هذه المشكلة بعض مشكلات الأداء المحددة في رقم 843 (وغيرها).

هل طلب الميزة الخاص بك متعلق بمشكلة؟
تم إنشاء القائمة المنسدلة / التحديد المتعدد الحالي الذي نشحنه مع IDS كطبقة تفاعل أعلى عنصر HTML <select> القياسي ، مع التعامل مع تحديد خياراته في كل من الإعدادات الفردية / المتعددة.

زادت حالات استخدام هذا المكون بمرور الوقت لتشمل تصفية الخيارات المتاحة ، مما أدى إلى استخدام الفرق القائمة المنسدلة / التحديد المتعدد لمجموعات البيانات الكبيرة للغاية (تتصدر أكثر من 2000 عنصر في وقت واحد ، في بعض الحالات). بينما يحتفظ فريقنا بأننا لا نوصي باستخدام هذا المكون لمجموعات البيانات بهذا الحجم ، فإننا نستمر في الحصول على مشكلات تطلب منا معالجة الأداء على هذه المستويات. تتضمن بعض المشكلات السابقة التي تم إصلاحها ما يلي:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• # 843 هو الأحدث

تترك العديد من هذه المشكلات تحذيرًا مفاده "هذا لا يزال غير رائع ولكنه أفضل". والسبب في ذلك هو أن تصميم Dropdown / Multiselect في جوهره لا يصلح لمجموعات البيانات بهذا الحجم. إذا أردنا إصلاح مشاكل الأداء ، فنحن بحاجة إلى معالجة أساسيات تصميمه.

صِف الحل الذي تريده
مسار حل محتمل لإصلاح أداء القائمة المنسدلة / التحديد المتعدد:

• [] مطلب صعب لاستخدام <select> كمصدر بيانات أساسي. بدأت بعض التحسينات الأخيرة من الرقم 267 في تحديد كيفية قيام مكالمة AJAX بإنشاء كائن بيانات لـ Dropdown يمكننا تخزينه على العميل. أعتقد أننا يجب أن نتحرك نحو استخدام كائن مع بعض الحالات البسيطة (معطل / محدد / إلخ) كمحرك أساسي لسلوك المكون ، بدلاً من الحصول على هذه المعلومات من عنصر DOM. سيظل عرض علامة <select> و <option> s ضروريين لأشياء مثل إرسال النموذج ، ولكن يجب علينا تعريف كائن البيانات على أنه "مصدر الحقيقة" ، ورسم علامة التحديد على أساس الكائن (وليس العكس).
• [] استكشف أيضًا عدم عرض / الاعتماد على علامة <select> بأي معنى. قد تكون حالة استخدام معقولة للمطور الذي يستخدم القائمة المنسدلة / التحديد المتعدد مع هذه العناصر العديدة ببساطة لاعتراض طلب تقديم النموذج ، وإرسال حالة كائن مصدر البيانات بدلاً من الاعتماد على عملية إرسال النموذج العادية. حاليًا ، هذا النوع من الاستخدام غير ممكن.
• [] بمجرد عدم اعتمادنا على عنصر DOM ، يمكننا البدء في استكشاف عرض مجموعة فرعية من عناصر القائمة في DOM في أي وقت. نظرًا لأنه يتم الاحتفاظ بالحالة بواسطة كائن مصدر البيانات ، فإن DOM لا يهم بالضرورة ، ويجب أن يكون تحميل / تفريغ كميات صغيرة من عناصر القائمة أكثر تافهاً أثناء قيام المستخدم بالتمرير عبر القائمة (سيسمح لنا باستكشاف # 460 على اسقاط).
• [] إنشاء توصيات أفضل للتعامل من جانب الخادم لمجموعات البيانات الكبيرة. حتى الاحتفاظ بالحالة في كائن من جانب العميل به العديد من السجلات يمكن أن يصبح بطيئًا جدًا في النهاية. قد نرغب في الحصول على توصية و / أو بعض العروض التوضيحية حول الكيفية التي قد نرغب بها في تطبيقات IDS للتعامل مع سجلات Dropdown / Multiselect على الخادم.

صِف البدائل التي فكرت فيها
بعض الأفكار الأخرى التي طرحناها في الماضي:

• مكون أبسط يقوم بتراكب علامات <select> ويقوم بتصميمها ، بدلاً من إنشاء ترميز زائف للتفاعلات. قد يكون هذا قادرًا على التعامل مع القائمة الأكبر بشكل أفضل لأنه لن يكررها. لا يزال يتعين علينا التعامل مع 2000 عنصر مرة واحدة في هذه الحالة.