Bagaimanakah Anda Akan Membina Komponen Autolengkap yang Boleh Diakses?

Gesaan dan Skop

Diberikan satu API carian, reka bentuk komponen autolengkap yang boleh diguna semula. Ia sepatutnya meminta selewat-lewatnya 10 cadangan selepas pengguna berhenti menaip selama 300 ms, dan API tersebut mempunyai kependaman p95 sebanyak 400 ms. Pada desktop dan mudah alih, ia mesti menyokong papan kekunci, tetikus, sentuhan, pembaca skrin, dan input IME, serta tidak boleh sama sekali memaparkan hasil untuk pertanyaan lama semasa menaip dengan pantas. Terangkan API komponen, model keadaan, permintaan tak segerak, semantik kebolehcapaian, pemegasan (caching), pengendalian ralat, dan pengujian.

Nombor-nombor tersebut merupakan andaian temu duga. Skop asas ialah komponen bahagian hadapan (frontend); pemeringkatan bahagian pelayan, pembetulan ejaan, pemperibadian, pemilihan berbilang (multi-select), dan penatalan tak terhingga adalah di luar skop. Sesuatu hasil boleh berupa teks biasa atau baris yang dirender secara tersuai, tetapi setiap hasil mesti mempunyai ID yang stabil dan label yang boleh dibaca. Komponen ini mengikut corak combobox yang boleh diedit dengan senarai cadangan pilihan tunggal.

Soalan ini sesuai untuk peranan frontend dan full-stack. Kemahiran terasnya ialah UI pelayar, keadaan tak segerak, dan interaksi yang boleh diakses, jadi kategorinya ialah frontend. Artikel Trie sedia ada menganggap carian awalan sebagai masalah struktur data dan menyebut Top K hanya sebagai susulan. Di sini API carian ialah kebergantungan yang telah diberikan; masalah bebasnya ialah perlumbaan di bahagian klien (client-side races), semantik fokus, tingkah laku IME, dan kontrak interaksi yang boleh disahkan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon memisahkan pengurangan permintaan daripada ketepatan. Debounce 300 ms mengurangkan permintaan semasa menaip berterusan, tetapi ia tidak menghalang permintaan yang lebih lama daripada kembali selepas permintaan yang lebih baharu. Jawapan yang kukuh menggabungkan pembatalan dengan jujukan permintaan yang meningkat secara monotonik dan hanya membenarkan permintaan terkini untuk pertanyaan semasa melakukan komit (commit) hasil.

Isyarat kedua ialah sama ada semantik kebolehcapaian membentuk kontrak yang lengkap. Penggayaan visual semata-mata tidak dapat menghubungkan input, pop timbul, dan pilihan. Fokus DOM harus kekal pada input manakala aria-activedescendant mengenal pasti pilihan yang aktif. aria-expanded, aria-controls, aria-autocomplete, listbox, option, dan aria-selected mesti berubah secara konsisten dengan keadaan yang kelihatan.

Isyarat ketiga ialah model input teks yang tepat. Bahasa Cina, Jepun, dan IME lain menghasilkan beberapa kemas kini semasa satu sesi gubahan (composition session). Mencari setiap rentetan perantaraan mencipta permintaan yang tidak relevan dan boleh mengganggu pemilihan calon perkataan. Komponen harus menjejaki gubahan dan menjadualkan carian untuk nilai yang dikomit selepas compositionend.

Isyarat keempat ialah sama ada keadaan dan UI boleh dibuktikan konsisten. Satu nilai boolean loading tunggal dan satu tatasusunan tidak dapat menyatakan dengan jelas pertanyaan pendek, pemuatan, kejayaan, hasil kosong, kegagalan, dan pop timbul yang ditutup. Jawapan yang kukuh mentakrifkan peralihan, ID pilihan yang stabil, tingkah laku pemulihan, dan peraturan untuk pilihan aktif selepas hasil berubah, kemudian menguji invarian tersebut dengan respons yang tidak mengikut urutan, papan kekunci, dan pembaca skrin.

Soalan Penjelasan Sebelum Menjawab

Apakah yang berlaku selepas sesuatu cadangan dipilih? Jika ia hanya mengisi input, panggil onSelect dan tutup senarai. Jika ia menavigasi serta-merta, kegagalan navigasi dan pemulihan input semasa kembali memerlukan kontrak mereka sendiri. Reka bentuk asas mengisi input dan mengeluarkan panggilan balik (callback).
Siapa yang mengawal nilai input? Sesuatu borang mungkin memerlukan value dan onValueChange; kotak carian kendiri mungkin menyokong nilai awal yang tidak dikawal. Komponen tidak boleh bertukar mod sepanjang jangka hayatnya.
Adakah hasil carian merupakan teks biasa? Hasil carian kaya memerlukan renderItem, tetapi getKey dan getLabel masih mesti menyediakan ID yang stabil dan nama yang boleh diakses. Menerima HTML sewenang-wenangnya meningkatkan risiko suntikan (injection risk).
Berapa banyak aksara yang memulakan carian? Nilai lalai asas ialah dua. Di bawah ambang tersebut, batalkan kerja yang belum selesai, tutup senarai, dan kosongkan pilihan aktif. Memaparkan sejarah untuk pertanyaan kosong memerlukan aria-autocomplete dan dasar cache yang berbeza.
Adakah Tab memilih cadangan yang aktif? Dalam reka bentuk asas, tidak; Tab meninggalkan widget. Jika produk bertegas bahawa Tab menerima cadangan, tingkah laku tersebut memerlukan komunikasi pengguna yang eksplisit dan pengujian berasingan berbanding mengatasi pergerakan fokus normal secara senyap.
Patutkah hasil lama kekal selepas ralat? Reka bentuk ini mengosongkannya dan menunjukkan ralat yang boleh dicuba semula supaya pengguna tidak tersilap menganggap cadangan pertanyaan lama sebagai pertanyaan semasa. Produk yang mengutamakan luar talian (offline-first) boleh memaparkan entri cache yang ditandakan sebagai mungkin basi, tetapi itu adalah kontrak yang berbeza.

Kerangka Jawapan 30 Saat

"Saya akan memisahkan pemaparan yang boleh disesuaikan daripada pengawal keadaan headless (headless state controller). Pengawal tersebut memegang pertanyaan, status permintaan, keadaan pop timbul, ID pilihan aktif, keadaan IME, dan jujukan permintaan terkini. Selepas input dikomit, ia melakukan debounce selama 300 milisaat dan membatalkan permintaan sebelumnya; sesuatu respons masih mesti sepadan dengan kedua-dua jujukan terkini dan pertanyaan semasa sebelum ia boleh melakukan komit. Input menggunakan semantik combobox dan mengekalkan fokus DOM, manakala kekunci anak panah mengemas kini aria-activedescendant, Enter membuat pemilihan, dan Escape menutupnya. Carian menunggu gubahan selesai, dan mesej status berasingan mengumumkan pemuatan, bilangan hasil, dan tiada hasil. Saya akan mengesahkannya dengan respons rangkaian yang disusun semula, matriks papan kekunci, input IME, pembaca skrin, dan pembatalan cache."

Perincian Langkah demi Langkah

Langkah 1: Tentukan sempadan dan API awam

Algoritma carian adalah milik pelayan. Komponen menerima fungsi pertanyaan dan dasar pemaparan. Antara muka neutral kerangka kerja boleh kelihatan seperti ini:

typescript

Autocomplete<T>({
  value,
  onValueChange,
  fetchSuggestions(query, signal),
  getKey(item),
  getLabel(item),
  renderItem,
  onSelect,
  minChars = 2,
  limit = 10,
  debounceMs = 300,
})

fetchSuggestions menerima AbortSignal supaya pemanggil boleh menyebarkan satu rantaian pembatalan ke rangkaian. getKey membekalkan ID DOM pilihan yang stabil, dan getLabel membekalkan kedua-dua teks isian dan nama yang boleh diakses. Pemaparan tersuai tidak boleh menggantikan semantik papan kekunci, fokus, atau pemilihan. Jika komponen mendedahkan panggilan balik perubahan nilai, sertakan sebab berstruktur seperti input, selection, atau clear supaya pengguna tidak menyimpulkan niat pengguna daripada perubahan rentetan semata-mata.

Langkah 2: Kekang pemaparan dengan mesin keadaan

Keadaan teras ialah:

query status = idle | loading | success | empty | error items isOpen activeId selectedItem isComposing latestRequestSeq

query ialah teks input semasa; selectedItem ialah pilihan yang telah disahkan. Kedua-duanya merupakan fakta yang berbeza dan tidak seharusnya berkongsi satu medan. Senarai boleh dibuka hanya apabila pertanyaan memenuhi panjang minimum, input masih berada dalam konteks interaktif, dan status mempunyai hasil atau maklum balas untuk dipaparkan. Kosongkan activeId apabila pertanyaan baharu bermula. Apabila hasil baharu tiba, kekalkan ID aktif yang lama hanya jika ia masih wujud; jika tidak, kosongkannya supaya aria-activedescendant tidak sekali-kali merujuk kepada nod yang hilang.

empty dan error adalah keadaan yang berbeza. Respons kosong adalah sah; ralat mungkin boleh dicuba semula. Menutup pop timbul tidak semestinya memusnahkan pertanyaan atau cache, tetapi ia mesti menetapkan semula isOpen dan activeId.

Langkah 3: Pisahkan debounce, pembatalan, dan komit hasil

Peristiwa input mula-mula mengemas kini query secara segerak. Jika gubahan sedang aktif, pertanyaan yang dinormalkan mempunyai kurang daripada dua aksara, atau ia hanya mengandungi ruang putih, kosongkan pemasa, batalkan permintaan semasa, dan tetapkan semula senarai. Jika tidak, mulakan permintaan selepas 300 ms. Aliran permintaan boleh dinyatakan sebagai pseudokod:

async function search(rawQuery) { const query = normalize(rawQuery) const seq = ++latestRequestSeq

controller?.abort() controller = new AbortController() setStatus("loading")

try { const items = await fetchSuggestions(query, controller.signal) if (seq !== latestRequestSeq || query !== normalize(currentQuery)) return commit(items.slice(0, 10)) } catch (error) { if (isAbort(error)) return if (seq === latestRequestSeq && query === normalize(currentQuery)) { commitError(error) } } }

AbortController boleh menghentikan permintaan Fetch yang belum selesai dan penggunaan badan respons, yang menjimatkan pemprosesan. Jujukan permintaan ialah pintu kawalan ketepatan. Operasi lama mungkin telah pun selesai, atau pemanggil mungkin menggunakan lapisan data yang tidak mematuhi sepenuhnya isyarat tersebut, jadi memanggil abort() sahaja tidak membuktikan bahawa hasil basi tidak boleh menulis ganti hasil baharu.

Dengan debounce 300 ms dan kependaman p95 API 400 ms, laluan p95 dari penekanan kekunci terakhir kepada hasil adalah sekitar 700 ms sebelum pemaparan. Penerbitan ini menjadikan kompromi (trade-off) tersebut jelas. Jika pengalaman perlu lebih pantas, gunakan cache pertanyaan tepat atau kurangkan debounce selepas mengukur kos permintaan; jangan mendakwa bahawa debounce 300 ms masih boleh menghasilkan respons tanpa cache dalam masa 150 ms.

Langkah 4: Kendalikan IME, penuding, dan fokus dengan betul

compositionstart menetapkan isComposing kepada true. Semasa gubahan, input mengemas kini teks yang kelihatan tetapi tidak menjadualkan carian. compositionend mengosongkan bendera tersebut dan menjadualkan satu carian untuk teks akhir yang dikomit. Peristiwa papan kekunci mungkin masih berlaku semasa gubahan aktif dan melaporkan isComposing, jadi Enter tidak boleh memilih cadangan pada masa tersebut. Uji pembalut peristiwa (event wrapper) kerangka kerja dalam pelayar sasaran dan bukannya menganggap input Bahasa Inggeris desktop mewakili setiap jujukan.

Pemilihan melalui tetikus dan sentuhan mesti mengambil kira kekaburan (blur) input sebelum klik dijalankan, yang boleh membuang pilihan yang diklik. pointerdown utama boleh mengekalkan fokus input, manakala click atau pointerup yang kekal dalam ambang pergerakan melengkapkan pemilihan melalui satu laluan yang dikongsi. Menatal senarai tidak boleh menukar pergerakan penuding biasa menjadi pemilihan. Klik di luar menutup pop timbul, manakala panggilan balik pemilihan tetap dijalankan tepat sekali.

Fokus DOM kekal pada input. Pilihan pop timbul dikecualikan daripada jujukan Tab, dan Tab mengikut tingkah laku lalai pelayar untuk meninggalkan widget. Ini mengekalkan tingkah laku penyuntingan teks asli dan mod input teknologi bantuan agar kekal stabil.

Langkah 5: Laksanakan kontrak combobox dan papan kekunci

Input mempunyai label yang kelihatan, atau mendapatkan namanya melalui aria-labelledby atau aria-label. Ia menggunakan role="combobox", aria-autocomplete="list", aria-expanded yang disegerakkan dengan pop timbul, aria-controls yang menghala ke senarai, dan aria-activedescendant hanya semasa pilihan aktif wujud.

Bekas cadangan menggunakan role="listbox". Setiap item mempunyai role="option" dan ID DOM yang stabil, dan item yang aktif secara visual juga mempunyai aria-selected="true". Anak Panah Bawah menjadikan pilihan pertama aktif dan kemudian bergerak ke bawah; Anak Panah Atas bergerak secara terbalik manakala fokus DOM kekal pada input. Reka bentuk asas berhenti pada sempadan dan bukannya berpusing semula (wrapping). Enter menerima pilihan yang aktif. Escape menutup pop timbul tetapi mengekalkan teks input.

Jangan memintas Left, Right, Home, End, Backspace, atau aksara yang boleh dicetak secara tanpa syarat. Combobox yang boleh diedit harus mengekalkan tingkah laku penyuntingan satu baris asli pelayar. Panggil preventDefault() hanya apabila komponen benar-benar mengendalikan pergerakan senarai, pemilihan, atau penolakan.

Senarai hasil tidak perlu menjadi kawasan langsung (live region) berkeutamaan tinggi pada setiap kemas kini. Gunakan elemen role="status" yang berasingan untuk mengumumkan "Mencari," "10 hasil," atau "Tiada hasil" tanpa mengalihkan fokus. Membuat pengumuman pada setiap penekanan kekunci boleh menjadikan widget tersebut terlalu bising.

Langkah 6: Batasi pemegasan dan pemulihan kegagalan

Kunci cache merangkumi sekurang-kurangnya pertanyaan yang dinormalkan, lokaliti, penapis, dan versi data. Pemegasan berasaskan pertanyaan sahaja mengembalikan data yang salah selepas pertukaran lokaliti atau penapis. Gunakan cache pertanyaan tepat dengan kedua-dua batas TTL dan had kapasiti. Data padanan cache (cache hit) boleh dipaparkan serta-merta, diikuti oleh penyegaran latar belakang hanya jika dasar kesegaran produk memerlukannya.

Respons dalam cache masih perlu melepasi semakan pertanyaan semasa dan jujukan permintaan. Mengosongkan input, memilih hasil, menyahlekap (unmounting) komponen, atau menukar kebergantungan akan membatalkan pemasa dan permintaan. Ralat pelayan mendedahkan tindakan cuba semula yang kecil; ia tidak menjadi baris yang boleh dipilih dalam senarai cadangan. Percubaan semula mencipta jujukan permintaan baharu, jadi ralat lama tidak boleh menulis ganti kejayaan yang terkemudian.

Serlahkan padanan dengan nod teks atau serpihan berstruktur yang dipercayai, bukannya markup pelayan yang tidak disanitasi. Enkod parameter pertanyaan dengan betul, dan jangan log pertanyaan sensitif yang penuh melainkan ia benar-benar diperlukan.

Langkah 7: Sahkan invarian dengan senario adversari

Ujian unit dengan jam terkawal membuktikan bahawa 299 ms tidak menyebabkan sebarang permintaan, 300 ms menyebabkan satu permintaan, menaip berterusan membatalkan pemasa sebelumnya, dan pertanyaan yang lebih pendek daripada dua aksara menetapkan semula keadaan. Ujian keadaan merangkumi kejayaan, hasil kosong, ralat, cuba semula, tutup, dan pemilihan.

Ujian perlumbaan (race test) memastikan respons perlahan untuk a tiba selepas respons pantas untuk ab; senarai akhir hanya boleh mengandungi hasil ab. Uji tiga laluan secara berasingan: permintaan yang boleh dibatalkan, permintaan yang telah selesai, dan lapisan data yang mengabaikan isyarat pembatalan.

Ujian interaksi merangkumi anak panah, Enter, Escape, Tab, klik, sentuhan, klik di luar, gubahan, dan pilihan aktif yang hilang selepas hasil berubah. Setiap langkah mengesahkan keadaan kelihatan, nilai input, bilangan panggilan balik, fokus DOM, dan atribut ARIA secara bersama.

Imbasan kebolehcapaian automatik hanya mengesan sebahagian daripada kontrak. Gunakan papan kekunci dan pembaca skrin sasaran untuk melengkapkan input, pemuatan, pengumuman hasil, pemilihan, hasil kosong, dan pemulihan ralat. Uji sentuhan dan papan kekunci perisian dalam pelayar mudah alih yang disokong. Ujian prestasi merekodkan taburan dari penekanan kekunci terakhir kepada hasil interaktif pertama, kadar pembatalan permintaan, kadar padanan cache, dan bilangan respons basi yang dibuang.

Contoh Jawapan Berkualiti Tinggi

"Saya akan mengehadkan skop ini kepada komponen cadangan pilihan tunggal frontend; API sedia ada mengendalikan carian dan pemeringkatan. Komponen menerima nilai terkawal, fungsi pertanyaan, kunci stabil, label yang boleh dibaca, pemapar baris tersuai, dan panggilan balik pemilihan. Secara dalaman, teks pertanyaan, objek yang dipilih, status permintaan, keadaan pop timbul, pilihan aktif, keadaan IME, dan jujukan permintaan kekal berasingan, supaya hasil kosong, ralat, dan pop timbul yang ditutup tidak runtuh menjadi satu nilai boolean tunggal.

Input dikemas kini serta-merta. Sebaik sahaja ia mempunyai dua aksara dan gubahan telah tamat, saya melakukan debounce selama 300 milisaat, membatalkan permintaan sebelumnya, dan memulakan permintaan berjujukan. Sesuatu respons hanya boleh dikomit jika jujukannya masih terkini dan pertanyaannya masih sepadan dengan input. Pembatalan menjimatkan kerja; penjujukan menjamin ketepatan. Andaian 300 ditambah 400 milisaat meletakkan laluan p95 tanpa cache pada sekitar 700 milisaat, jadi kependaman sebenar dan kos permintaan harus menentukan tempoh debounce.

Dari segi semantik, input yang dinamakan ialah combobox yang mengawal listbox. Fokus DOM kekal pada input; kekunci anak panah menukar aria-activedescendant yang stabil, Enter membuat pemilihan, Escape menutup, dan Tab keluar seperti biasa. Pilihan menggunakan option dan aria-selected, manakala kawasan status yang berasingan mengumumkan pemuatan, bilangan hasil, dan tiada hasil. Carian dan pemilihan Enter kedua-duanya digantung semasa gubahan.

Cache dibatasi oleh TTL dan kapasiti serta menggunakan kunci pertanyaan yang dinormalkan, lokaliti, dan penapis. Saya akan mengesahkan respons lama-perlahan berbanding baharu-pantas, IME, tingkah laku papan kekunci dan pembaca skrin, kekaburan penuding, hasil kosong, cuba semula, dan pembatalan cache. Kejayaan bermakna setiap hasil yang kelihatan adalah milik pertanyaan semasa dan keadaan fokus serta kebolehcapaian sepadan dengan keadaan visual pada setiap peralihan."

Kesilapan Biasa

Hanya melakukan debounce → Debounce mengurangkan permintaan tetapi tidak menyusun urutan respons → Tambah pembatalan dan kawal komit berdasarkan kedua-dua jujukan terkini dan pertanyaan semasa.
Hanya memanggil abort() → Kerja lama mungkin telah pun selesai atau lapisan data mungkin mengabaikan isyarat tersebut → Anggap pembatalan sebagai pengoptimuman dan semakan jujukan sebagai syarat ketepatan.
Menggunakan indeks tatasusunan sebagai item aktif → Indeks yang sama mungkin mengenal pasti hasil yang berbeza selepas penyusunan semula → Gunakan ID hasil yang stabil dan sahkan ia masih wujud selepas menggantikan senarai.
Mengalihkan fokus DOM ke dalam setiap pilihan → Fokus input, penyuntingan teks, dan teknologi bantuan boleh menyimpang → Kekalkan fokus pada input dan dedahkan item aktif melalui aria-activedescendant.
Memintas setiap peristiwa papan kekunci → Tingkah laku penyuntingan Home, End, anak panah, dan IME asli akan rosak → Pintas hanya kekunci yang benar-benar digunakan oleh komponen untuk navigasi senarai, pemilihan, atau penolakan.
Mencari pada setiap kemas kini IME → Teks fonetik yang belum dikomit menghasilkan permintaan yang salah, dan Enter mungkin memilih secara tidak sengaja → Jejaki sesi gubahan dan cari hanya selepas ia tamat.
Menjadikan keseluruhan senarai hasil sebagai pengumuman mendesak → Setiap kemas kini input mencetuskan ucapan yang meleret-leret → Gunakan mesej role="status" yang terkawal untuk pemuatan, bilangan, dan hasil kosong.
Membuat cache mengikut pertanyaan sahaja → Perubahan lokaliti atau penapis boleh mencapai data yang salah → Letakkan setiap syarat yang mempengaruhi hasil dan versi ke dalam kunci, bersama had TTL dan kapasiti.

Soalan Susulan dan Cara Mengendalikannya

Susulan 1: Apakah yang berubah jika senarai mesti memaparkan 1,000 hasil?

Cabar keperluan itu terlebih dahulu: autolengkap biasanya perlu memeringkatkan dan mengehadkan set cadangan kecil yang relevan. Jika menyemak imbas set yang besar diperlukan, tambahkan windowing (virtualisasi). Pilihan yang aktif mesti kekal terlekap (mounted), atau diskrol ke dalam tetingkap terlekap sebelum mengemas kini aria-activedescendant; atribut tersebut tidak boleh merujuk kepada nod yang telah divirtualisasikan keluar. Dedahkan semantik kedudukan dan saiz keseluruhan yang bermakna dan sahkan ia dengan pembaca skrin, bukan sekadar pengukuran kadar bingkai (frame rate).

Susulan 2: Bagaimanakah berbilang halaman boleh berkongsi permintaan dan entri cache?

Pindahkan storan cache dan penyahduplikasian permintaan ke dalam lapisan data peringkat halaman manakala komponen masih hanya menggunakan fetchSuggestions. Kunci yang dikongsi merangkumi lokaliti, penapis, skop kebenaran, dan versi data. Panggilan untuk kunci yang sama boleh berkongsi satu Promise, tetapi setiap komponen mengekalkan jujukan permintaannya sendiri kerana dua input boleh mempunyai pertanyaan semasa dan masa nyahlekap yang berbeza.

Susulan 3: Bagaimanakah anda akan menambah sejarah tempatan dan cadangan pertanyaan kosong?

Tandakan setiap sumber sebagai history atau remote, kemudian tentukan pemadaman, privasi, dan penyegerakan merentas peranti. Sejarah pada pertanyaan kosong ialah keadaan yang berasingan daripada melengkapkan input yang ditaip, jadi ia memerlukan aria-autocomplete, tajuk, dan dasar pengumuman yang eksplisit. Pemilihan sejarah masih mengikut kontrak ID stabil, dan carian sensitif tidak boleh dikekalkan secara lalai.

Susulan 4: Bagaimanakah ini berfungsi dengan pemaparan pelayan (server rendering) dan penghidratan (hydration)?

Pelayan boleh merender label dan input kosong, manakala klien mengendalikan pop timbul interaktif. ID input, senarai, dan pilihan mesti stabil merentas pelayan dan klien; ID rawak pada pemaparan pertama boleh merosakkan aria-controls selepas penghidratan. Jika pelayan pramuat cadangan, sirikan kunci cache, pertanyaan, dan versi data bersama-sama dan guna semula muatan hanya apabila ketiga-tiganya masih sepadan.

Susulan 5: Bagaimanakah anda akan mengubah suai komponen untuk menyokong cip pemilihan berbilang (multi-select chips)?

Itu mengubah semantik fokus, pemadaman, dan item yang dipilih; menggantikan selectedItem dengan tatasusunan adalah tidak mencukupi. Tentukan pergerakan kiri dan kanan antara input dan cip, pengesahan Backspace, duplikasi, bilangan maksimum, dan pengumuman pembaca skrin. Senarai cadangan boleh kekal sebagai combobox, tetapi cip yang dipilih memerlukan kawasan boleh dinavigasi mereka sendiri serta semakan pengujian papan kekunci dan teknologi bantuan yang baharu.