Enterprise: Dropdown/Multiselect: Refactor untuk menggunakan objek sumber data sebagai lawan dari elemen Select

CATATAN: Masalah ini berpotensi mengatasi beberapa masalah kinerja yang diidentifikasi di #843 (dan lainnya).

Apakah permintaan fitur Anda terkait dengan masalah?
Dropdown/Multiselect saat ini yang kami kirimkan dengan IDS dibuat sebagai lapisan interaksi di atas elemen HTML <select> standar, menangani pemilihan opsi di kedua pengaturan tunggal/multiple.

Kasus penggunaan untuk komponen ini telah meningkat dari waktu ke waktu untuk menyertakan pemfilteran opsi yang tersedia, yang menyebabkan tim menggunakan Dropdown/Multiselect untuk kumpulan data yang sangat besar (melebihi 2000 item sekaligus, dalam beberapa kasus). Meskipun tim kami menyatakan bahwa kami tidak menyarankan penggunaan komponen ini untuk kumpulan data sebesar ini, kami terus mendapatkan masalah yang meminta kami untuk mengatasi kinerja pada tingkat ini. Beberapa masalah sebelumnya yang telah kami perbaiki meliputi:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 menjadi yang terbaru

Banyak dari masalah tersebut meninggalkan peringatan "ini masih tidak bagus tapi lebih baik". Alasan untuk ini adalah karena desain Dropdown/Multiselect pada intinya tidak cocok untuk kumpulan data sebesar ini. Jika kita ingin memperbaiki masalah kinerja, kita perlu mengatasi dasar-dasar desainnya.

Jelaskan solusi yang Anda inginkan
Jalur solusi yang mungkin untuk memperbaiki kinerja Dropdown/Multiselect:

• [ ] Persyaratan sulit untuk menggunakan <select> sebagai sumber data utama. Beberapa peningkatan terbaru dari #267 mulai memetakan bagaimana panggilan AJAX dapat menghasilkan objek data untuk Dropdown yang dapat kami simpan di klien. Saya pikir kita harus beralih ke penggunaan objek dengan beberapa status sederhana (dinonaktifkan/dipilih/dll) sebagai pendorong utama perilaku komponen, alih-alih mengambil informasi ini dari elemen DOM. Render tag <select> dan <option> s masih diperlukan untuk hal-hal seperti pengiriman formulir, tetapi kita harus mendefinisikan objek data sebagai "sumber kebenaran", dan menggambar tag pilih berdasarkan objeknya (bukan sebaliknya).
• [ ] Juga jelajahi dengan tidak merender/memiliki ketergantungan pada tag <select> dalam arti apa pun. Ini mungkin kasus penggunaan yang masuk akal bagi pengembang yang menggunakan Dropdown/Multiselect dengan banyak item ini untuk sekadar mencegat permintaan pengiriman formulir, dan mengirim status objek sumber data alih-alih mengandalkan proses pengiriman formulir normal. Saat ini, jenis penggunaan ini tidak memungkinkan.
• [ ] Setelah kita tidak lagi mengandalkan elemen DOM, kita dapat mulai menjelajahi hanya menampilkan subset item daftar di DOM pada waktu tertentu. Karena status dipertahankan oleh objek sumber data, DOM tidak selalu penting, dan seharusnya jauh lebih sepele untuk memuat/membongkar sejumlah kecil item daftar saat pengguna menggulir daftar (akan memungkinkan kita untuk menjelajahi #460 di tarik-turun).
• [ ] Buat rekomendasi yang lebih baik untuk penanganan set data besar di sisi server. Bahkan mempertahankan status di objek sisi klien dengan banyak catatan pada akhirnya bisa menjadi sangat lambat. Kami mungkin ingin memiliki rekomendasi dan/atau beberapa demo tentang bagaimana kami mungkin menginginkan implementasi IDS untuk menangani catatan Dropdown/Multiselect di server.

Jelaskan alternatif yang telah Anda pertimbangkan
Beberapa ide lain yang telah kami kemukakan sebelumnya:

• Komponen sederhana yang melapisi tag <select> dan menatanya, alih-alih menghasilkan markup semu untuk interaksi. Ini mungkin dapat menangani daftar yang lebih besar dengan lebih baik karena tidak akan menduplikasinya. Kami masih harus menangani elemen 2000ish sekaligus dalam kasus ini.