Enterprise: Kontrol dropdown multiselect memiliki kinerja yang buruk di IE11 ketika daftar dropdown berisi +500 opsi

Hasil pengujian kami untuk ini tampaknya jauh lebih baik daripada angka-angka itu bagi saya.
http://master-enterprise.demo.design.infor.com/components/dropdown/test-2000-items.html

Mungkin ada masalah dengan multi pilih secara khusus. Mereka memiliki kode yang sama tetapi beberapa jalur berbeda.

Pada akhirnya kode tes apakah Anda memilikinya? Atau banyak drop down?

@tmcconechy , untuk pengujian saya, saya memiliki 5 kontrol multiselect di halaman. Ketika saya mengubah kontrol tersebut menjadi dropdown (non-multiselect), saya melihat peningkatan kinerja yang signifikan. Masalah ini tampaknya khusus untuk kontrol multipilihan.

Membahas masalah ini, sedikit penasaran dengan use case yang sebenarnya? Pilihan multiselect macam apa yang dibuat pengguna?

@picitelli adalah orang terbaik untuk diajak bicara.
Dari pemahaman saya, daftar perlu dibuat setiap kali dropdown digunakan dan bisa ada di mana saja hingga sekitar 2000 item tergantung pada peran pengguna. Mereka perlu memuat ulang dropdown pada titik-titik tetapi tidak dapat berkomunikasi dengan plugin dari Mongoose.
Tidak yakin pilihan multiselect macam apa yang sedang dibuat.
Saya telah membaca banyak tentang IE11 yang memiliki kinerja buruk saat menambahkan item ke DOM secara umum dan akan menyertakan beberapa tautan di bawah ini.
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-enormously-slow

Jelas IE lambat di DOM tetapi saya bertanya-tanya kasus penggunaan aktual di mana pengguna diperlihatkan 500 hal dan harus memilih yang mana. Sepertinya mungkin maksimal 50 pilihan akan lebih tepat untuk UI keputusan/pemilihan.

Kita mungkin bisa membuatnya lebih cepat, tetapi bertanya-tanya apakah use case akan lebih baik dilayani oleh komponen yang berbeda.

Pasti akan lebih baik dilayani oleh komponen yang berbeda, tetapi permintaan klien adalah menggunakan dropdown. Apakah kami ingin kembali dan mengatakan, ini bukan komponen yang tepat dan Anda akan mengalami masalah di IE11...mungkin meningkatkan ke Edge? Saya kira kita bisa menawarkan saran.

@tmcconechy , untuk aplikasi kami, kami memiliki 4 kontrol dropdown multi-pilih yang dapat diakses pengguna untuk memfilter hasil pada halaman daftar pesanan. Jumlah opsi yang muncul dalam dropdown ini didasarkan pada pilihan pengguna dan juga izin (peran) yang diberikan pengguna. Pengguna biasa akan dibatasi untuk hanya melihat sejumlah kecil opsi. Setelah mereka membuat pilihan, kami memiliki panggilan API yang mengisi lebih banyak opsi di kontrol tarik-turun sekunder yang digunakan untuk pemfilteran tambahan. (Dropdown ini berkomunikasi satu sama lain.)

Pengguna dengan izin admin penuh akan melihat semua opsi dalam kontrol tarik-turun. Saat ini, jumlah total opsi adalah 1969. Jumlah itu dapat bertambah, berdasarkan apa yang ingin digunakan klien.

Pengguna mungkin hanya melihat 2-50 opsi dalam kontrol, tetapi jika mereka diberikan izin tambahan, jumlah opsi yang mereka miliki dapat diperluas hingga 1969. Kami tidak ingin menawarkan kontrol lain (mis. pencarian produk) yang menambahkan langkah tambahan bagi mereka untuk berinteraksi dan melakukan proses pemfilteran ketika kontrol multi-pilih adalah opsi terbaik, terutama ketika sebagian besar pengguna akan melihat lebih sedikit opsi.

IE11 membuat frustrasi untuk ditangani, dan saya tahu kinerjanya tidak optimal ketika ada begitu banyak opsi dalam kendali. Kontrol yang sama ini, digunakan tanpa pengaturan "beberapa", dan karena hanya satu pilihan dropdown tidak memiliki masalah kinerja yang sama di IE11 ketika ada ~ 2000 opsi. Hanya sebagai multiselect ada masalah kinerja besar ini.

Saya juga berharap itu sesederhana memberitahu mereka untuk meng-upgrade browser mereka tetapi aplikasi ini untuk pelanggan klien, yang didominasi di IE11.

@tmcconechy @EdwardCoyle
Saya telah bekerja dengan berbagai solusi untuk mengoptimalkan kode ini untuk IE dan belum menemukan solusi apa pun yang, setelah diterapkan, meningkatkan kinerja di IE11. Rekomendasi saya pada saat ini adalah untuk mendorong kembali dan menyarankan komponen yang berbeda jika mereka menginginkan kinerja yang lebih baik. Sampai sekarang, dropdown dan multiselect keduanya berkinerja sangat baik dengan hingga 500 item. 2000 seperti yang diminta dalam masalah ini bagi saya tampaknya berlebihan untuk komponen seperti itu.
Senang menerima saran atau diskusi apa pun selain dari utas komentar ini.

@picitelli jika permintaannya adalah agar kami mendukung IE11 dalam kondisi seperti itu, solusinya tidak langsung. Komponen Dropdown kami akan membutuhkan perbaikan yang cukup serius, karena tidak pernah dirancang dengan jenis beban dalam pikiran.

@davidcarlsonberg @clepore @nickwynja @tmcconechy kita harus mengobrol tentang yang satu ini. Saya punya beberapa ide untuk menangani kinerja tetapi ide-ide itu mendarat di wilayah "refactoring".

Saya pikir ada perbedaan besar antara dropdown dengan 2000 dan multiselect dengan 2000. Apakah Anda menjelajahi perbedaan kecepatan di sana untuk mendapatkan keuntungan yang lebih cepat.

Saya lebih melihat akar penyebab penurunan kinerja. Saya dapat menyelidiki dropdown multiselect vs dropdown biasa jika kami ingin mengubah cakupan tiket ini untuk melihat apa yang dapat diperoleh di sana untuk kemenangan cepat.

Ya, ini pasti layak untuk dilihat. Saya mendasarkan asumsi ini pada komentar ini https://github.com/infor-design/enterprise/issues/843#issuecomment -424495956

Apa pun mungkin membantu meskipun hanya "sedikit" lebih cepat

Saya akan melanjutkan untuk menentukan dan meningkatkan perbedaan antara dropdown dan multiselect.

Saya pikir @EdwardCoyle benar karena kita perlu merombak ini dari bawah ke atas menggunakan teknik yang lebih modern untuk efisiensi. Saya tidak yakin apakah layak menghabiskan lebih dari sehari untuk @davidcarlsonberg ini.

@picitelli Kami akan terus mencari opsi untuk mengatasi kasus tepi kinerja ini.

Saya pikir opsi terbaik untuk kasus ini adalah menggunakan indikator sibuk :

Indikator sibuk memberi tahu pengguna bahwa sistem sedang memproses permintaan, dan mereka harus menunggu permintaan itu diproses sebelum melanjutkan tugas saat ini.

Berikut ini contoh penggunaannya di bidang:

• 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

Pengalaman terbaik adalah menunggu sekitar satu detik dan hanya menampilkan indikator sibuk jika daftar belum muncul.

Setelah diperiksa di Chrome baru-baru ini di macOS, perbedaan dalam waktu eksekusi dropdown vs multiselect response() . Harap dicatat unit.
tarik-turun: 512,14 ms
pilihan ganda: 1,02 dtk

@tmcconechy @davidcarlsonberg @EdwardCoyle @clepore Saya menghargai semua orang yang melihat masalah ini. Terutama @davidcarlsonberg , terima kasih telah menghabiskan waktu Anda untuk ini. Kami telah mencoba selama hampir 2 minggu untuk mengoptimalkan IE11 dan hanya menemui jalan buntu. Saya setuju dengan penilaian bahwa kontrol ini tidak dimaksudkan untuk menangani banyak opsi ini dan kontrol lain akan lebih cocok.

@nickwynja , akan mengambil rekomendasi indikator sibuk Anda dengan desain dan melihat apa yang mereka katakan.

Terima kasih lagi semua!

Menutup masalah ini karena tidak ada pengujian QA yang terlibat. Silakan lihat komentar untuk info lebih lanjut.