Chosen: UI tergantung pada daftar yang sangat besar

Dibuat pada 28 Mar 2016 · 4Komentar · Sumber: harvesthq/chosen

Versi 1.5.1;
Browser yang diuji: Chrome, Safari;
diasumsikan berlaku secara universal

Saat bekerja dengan /truly/ pilihan besar (elemen 20K), respons pemfilteran meninggalkan sedikit hal yang diinginkan.
Saya pikir dua aspek utama dapat ditingkatkan secara dramatis:
1) ketika mengklik untuk menyebabkan kotak pilih terbuka, jangan mencari setiap item dengan regex kosong, cukup isi daftar lengkap - ini akan mengurangi waktu pembukaan pilih secara dramatis dan itu mungkin bagian paling nyata dari masalah pengalaman pengguna.
2) Saat mengetik, pencarian harus memiliki opsi untuk di-debounce (idealnya dengan durasi yang ditentukan konfigurasi?) sehingga pengguna dapat mengetik beberapa karakter sebelum benar-benar mulai mencari. Mungkin ini bahkan bisa dilakukan dengan cerdas berdasarkan jumlah kecocokan yang sudah ada sebelumnya sebelum mencari (jika menampi daftar yang sudah kecil, jangan debounce terlalu lama)

Saya sendiri sedang mencari detail implementasi, tetapi jika salah satu pelanggan tetap di sekitar sini melihat cara mudah menambahkan satu atau keduanya dan dapat melakukannya (atau mengarahkan saya ke mana harus melakukannya) itu akan bagus.

Performance

Sumber

mcclurem

👍1

Komentar yang paling membantu

Opsi RE 2

Sementara max_shown_results mempercepat pencarian secara dramatis (saya memiliki daftar 22k elemen), kami memerlukan beberapa cara untuk menunjukkan bahwa ada item tambahan yang disembunyikan.

Saya menyarankan sesuatu di sepanjang baris "Tampilkan lebih banyak" / "Tampilkan x berikutnya" di bagian bawah daftar untuk menampilkan x tambahan (Di mana x = max_shown_results). Sementara ini sebagian akan meniadakan kecepatan yang disediakan oleh batasan asli, ini akan menunjukkan bahwa daftar berisi item tambahan. Alternatif hanya akan menjadi sesuatu seperti "..." di bagian bawah berwarna abu-abu untuk menunjukkan opsi tersembunyi tambahan (Mungkin teks yang dapat diubah pengguna dalam inisialisasi?)

Reelix pada 23 Mei 2016

👍6

Semua 4 komentar

@mcclurem Terima kasih atas laporan Anda!

Ada beberapa masalah sebelumnya tentang masalah kinerja dengan ribuan opsi — lihat #2158 sebagai contoh.

Adapun dua catatan spesifik Anda:

Memanggil regex kosong yang tidak perlu pada setiap elemen saat terbuka memang tampak buruk! Silakan menyelidiki solusi dan mengirimkan PR untuk memperbaikinya jika memungkinkan.
Kami secara historis menolak "pencarian tertunda hingga _n_ karakter" semacam itu karena masalah UX. Lihat #2359 dan masalah terkaitnya. _Namun_, ada solusi alternatif: max_shown_results diperkenalkan di #2362. Itu secara khusus ditambahkan "untuk meningkatkan kinerja pilihan dengan sangat banyak opsi", jadi ini mungkin yang Anda cari. Informasi lebih lanjut tentang max_shown_results dapat ditemukan di dokumen .

tjschuck pada 28 Mar 2016

Opsi RE 2

Sementara max_shown_results mempercepat pencarian secara dramatis (saya memiliki daftar 22k elemen), kami memerlukan beberapa cara untuk menunjukkan bahwa ada item tambahan yang disembunyikan.

Reelix pada 23 Mei 2016

👍6

@mcclurem Apa yang Anda lakukan untuk daftar besar Anda di Terpilih? Apakah Anda dapat menemukan solusi yang masuk akal? Apakah Anda mengubah cara Anda memuat nilai ke dalam pilihan? Apakah ada cara yang lebih baik untuk malas memuat dengan masih melakukan pencarian? Kami melihat memiliki 100.000 item dalam hasil kami. Saat ini kami membatasi tampilan untuk hanya menampilkan 50. Tetapi sisi klien pencarian akan membutuhkannya dimuat untuk dipilih untuk melakukan pencarian.

steckdev pada 4 Jan 2017

👍1

+1. Kontra utama dari plugin ini saya pikir akan menjadi kinerja dan mengharapkan sesuatu seperti pemuatan malas akan menyelesaikan masalah. Ini adalah satu-satunya celah besar yang saya lihat dalam pemilihan.