Enterprise: التحكم في القائمة المنسدلة متعدد التحديد له أداء ضعيف في IE11 عندما تحتوي القائمة المنسدلة على +500 خيار

تبدو إعادة الاختبار في اختبارنا لهذا أفضل بكثير من تلك الأرقام بالنسبة لي.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

ربما هناك مشكلة في التحديد المتعدد على وجه التحديد. لديهم نفس الكود ولكن بعض المسارات المختلفة.

في رمز الاختبار النهائي هل كان لديك واحد؟ أو العديد من القوائم المنسدلة؟

tmcconechy ، بالنسبة للاختبار لدي 5 عناصر تحكم متعددة التحديد على الصفحة. عندما أقوم بتغيير عناصر التحكم هذه إلى قائمة منسدلة (غير متعددة التحديد) ، لاحظت تحسنًا كبيرًا في الأداء. يبدو أن هذه المشكلة خاصة بضوابط التحديد المتعدد.

مناقشة هذه المسألة ، هل لديك فضول بعض الشيء حول حالة الاستخدام الفعلي؟ ما نوع الاختيارات المتعددة التي يتخذها المستخدم؟

picitelli هو أفضل شخص يمكن التحدث إليه.
حسب فهمي ، يجب إنشاء القائمة في كل مرة يتم فيها مشاركة القائمة المنسدلة ويمكن أن يكون هناك ما يصل إلى 2000 عنصر في أي مكان حسب دور المستخدم. يحتاجون إلى إعادة تحميل القائمة المنسدلة في نقاط ولكن لا يمكنهم الاتصال بالمكوِّن الإضافي من Mongoose.
لست متأكدًا من نوع الاختيارات المتعددة التي يتم اتخاذها.
لقد قرأت كثيرًا عن أداء IE11 الضعيف في إضافة عناصر إلى DOM بشكل عام وسوف تتضمن بعض الروابط أدناه.
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/4561410/
https://stackoverflow.com/questions/43003579/internet-explorer-11-very-slow-appending-elements-to-dom
https://stackoverflow.com/questions/24913564/appending-large-groups-of-elements-in-ie11-enormually-slow

بالتأكيد IE بطيء على DOM ولكني كنت أتساءل عن حالة الاستخدام الفعلية حيث يظهر للمستخدم 500 شيء وعليه اختيار أي منها. يبدو أنه ربما يكون 50 خيارًا كحد أقصى أكثر ملاءمة لواجهة مستخدم للقرار / التحديد.

ربما يمكننا أن نجعلها أسرع ، لكن نتساءل عما إذا كان من الأفضل تقديم حالة الاستخدام بواسطة مكون مختلف.

من المؤكد أنه سيتم تقديمه بشكل أفضل من خلال مكون مختلف ، لكن العميل يطلب استخدام القائمة المنسدلة. سواء كنا نريد العودة والقول ، هذا ليس المكون الصحيح وستواجه مشكلات في IE11 ... ربما الترقية إلى Edge؟ أفترض أنه يمكننا تقديم الاقتراح.

tmcconechy ،

سيرى المستخدم الذي لديه أذونات المسؤول الكاملة جميع الخيارات ضمن عنصر التحكم في القائمة المنسدلة. في الوقت الحالي ، إجمالي عدد الخيارات هو 1969. يمكن أن ينمو هذا الرقم بناءً على ما يريد العميل استخدامه.

قد يرى المستخدم فقط من 2 إلى 50 خيارًا ضمن عنصر التحكم ، ولكن إذا تم منحهم أذونات إضافية ، فيمكن أن يتوسع حجم الخيارات المتاحة لديهم حتى عام 1969. لا نريد تقديم عنصر تحكم آخر (مثل البحث عن المنتج) يضيف خطوة إضافية لهم للتفاعل مع عملية التصفية وتنفيذها عندما يكون عنصر التحكم متعدد التحديد هو الخيار الأفضل ، خاصة عندما يرى غالبية المستخدمين عددًا أقل من الخيارات.

IE11 محبط للتعامل معه ، وأنا أعلم أن الأداء ليس هو الأمثل عندما يكون هناك العديد من الخيارات داخل التحكم. نفس عنصر التحكم هذا ، المستخدم بدون الإعداد "متعدد" ، وكقائمة منسدلة واحدة فقط لا تحتوي على نفس مخاوف الأداء في IE11 عندما يكون هناك حوالي 2000 خيار. فقط كاختيار متعدد توجد مشكلة الأداء الكبيرة هذه.

أتمنى أيضًا أن يكون الأمر بسيطًا مثل إخبارهم بترقية متصفحهم ولكن هذا التطبيق مخصص لعملاء العملاء ، والذين يتواجدون في الغالب على IE11.

تضمين التغريدة
لقد كنت أعمل مع حلول مختلفة لتحسين هذا الرمز لـ IE ولم أجد أي حل ، بمجرد تنفيذه ، يزيد من الأداء في IE11. توصيتي في هذه المرحلة بالرد واقتراح مكون مختلف إذا كانوا يرغبون في أداء أفضل. اعتبارًا من الآن ، تعمل كل من القائمة المنسدلة والتحديد المتعدد بشكل جيد للغاية مع ما يصل إلى 500 عنصر. 2000 كما هو مطلوب في هذه المسألة يبدو لي أنه مفرط لمثل هذا المكون.
يسعدني تلقي أي نصيحة أو مناقشة بصرف النظر عن سلسلة التعليقات هذه.

picitelli إذا كان الطلب منا هو دعم IE11 في ظل هذه الظروف ، فإن الحل ليس واضحًا. سيحتاج مكون القائمة المنسدلة الخاص بنا إلى إصلاح شامل للغاية ، حيث لم يتم تصميمه مع وضع هذا النوع من الحمل في الاعتبار.

MustafaHosny اللهم امين ههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههه لدي بعض الأفكار حول معالجة الأداء ولكن هذه الأفكار تهبط في منطقة "إعادة البناء".

اعتقدت أن هناك فرقًا كبيرًا بين القائمة المنسدلة مع 2000 و multiselect مع 2000. هل استكشفت الفرق في السرعة هناك لتحقيق مكاسب فورية أكثر.

كنت أبحث أكثر في السبب الجذري لانخفاض الأداء. يمكنني التحقيق في القائمة المنسدلة متعددة التحديدات مقابل القائمة المنسدلة العادية إذا أردنا تغيير نطاق هذه التذكرة لمعرفة ما يمكن كسبه هناك لتحقيق فوز سريع.

نعم ، إنه بالتأكيد يستحق نظرة كنت أسند هذا الافتراض على هذا التعليق https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

قد يساعد أي شيء حتى لو كان أسرع "قليلاً"

سأشرع في تحديد وتحسين الفرق بين القائمة المنسدلة والاختيار المتعدد.

أعتقد أن EdwardCoyle محق في أننا سنحتاج إلى إصلاح هذا من الألف إلى الياء باستخدام تقنيات أكثر حداثة لتحقيق الكفاءة. لست متأكدًا مما إذا كان الأمر يستحق إنفاق أكثر من يوم على هذا davidcarlsonberg .

picitelli سنستمر في النظر في الخيارات لمعالجة حالة حافة الأداء هذه.

أعتقد أن أفضل خيار لهذه الحالة هو استخدام مؤشر مشغول :

يقوم مؤشر مشغول بإعلام المستخدم بأن النظام يقوم بمعالجة طلب ، وأنه يجب عليه الانتظار حتى تتم معالجة هذا الطلب قبل متابعة المهمة الحالية.

فيما يلي مثال على استخدامه في أحد الحقول:

• https://design.infor.com/code/ids-enterprise/4.10.0/demo/busyindicator/example-inputs؟font=source-sans
• https://github.com/infor-design/enterprise/blob/4.10.0/app/views/components/busyindicator/example-inputs.html

ستكون أفضل تجربة هي الانتظار لمدة ثانية أو نحو ذلك وعرض مؤشر مشغول فقط إذا لم تظهر القائمة بعد.

عند الفحص في Chrome الأخير على macOS ، فإن الفرق في القائمة المنسدلة مقابل التحديد المتعدد response() وقت التنفيذ. يرجى ملاحظة الوحدات.
منسدل: 512.14 مللي ثانية
التحديد المتعدد: 1.02 ثانية

tmcconechydavidcarlsonbergEdwardCoyleclepore وأنا أقدر كل شخص يبحث في هذه المسألة. خاصة davidcarlsonberg ، شكرًا لقضاء وقتك في هذا. لقد كنا نحاول منذ ما يقرب من أسبوعين من جانبنا تحسين IE11 ولم نواجه شيئًا سوى طرق مسدودة. أتفق مع التقييم القائل بأن هذا التحكم لم يكن المقصود منه التعامل مع هذه الخيارات العديدة وأن عنصر تحكم آخر سيكون أكثر ملاءمة.

nickwynja ، ستأخذ توصية المؤشر المشغولة بالتصميم وترى ما يقولونه.

شكرا مرة أخرى جميعا!

إغلاق هذه المشكلة نظرًا لعدم وجود اختبار ضمان الجودة. يرجى الاطلاع على التعليقات لمزيد من المعلومات.