Prompt dan Konteks Berkenaan
Bina aliran pengesahan untuk borang daftar keluar yang mengandungi e-mel, negara, poskod, tarikh penghantaran, dan kod diskaun pilihan. Peraturan poskod bergantung pada negara. Kod diskaun disemak oleh perkhidmatan jauh. Pelayan kekal berautoriti bagi harga, stok, peraturan alamat, dan kesahihan kod.
Borang mestilah berfungsi dengan papan kekunci dan teknologi bantuan, pada zum 200%, serta selepas round trip ke pelayan. Ralat tidak boleh disampaikan melalui warna semata-mata. Penyerahan yang gagal mesti mengekalkan nilai yang telah dimasukkan, mengenal pasti setiap ralat yang boleh diambil tindakan, dan menyediakan laluan pemulihan langsung. Kegagalan rangkaian, kod yang tamat tempoh, dan respons tak segerak yang lebih baharu mengatasi respons lama adalah sebahagian daripada masalah yang perlu ditangani.
Matlamatnya bukan untuk mencipta pustaka borang yang baharu. Jawapan hendaklah mentakrifkan keadaan (state), pemasaan pengesahan, hubungan semantik, dasar fokus, dan kontrak ralat klien-pelayan, kemudian menunjukkan cara keputusan tersebut disahkan. Kekangan HTML natif adalah garis asas; tingkah laku tersuai mesti menambah kejelasan tanpa membuang semantik pelayar.
Perkara yang Dinilai oleh Penemu Duga
Isyarat pertama ialah tanggungjawab. Pengesahan klien memberikan maklum balas pantas dan mengelakkan permintaan yang tidak perlu. Pengesahan pelayan menentukan sama ada pesanan diterima. Calon yang mempercayai atribut required di bahagian klien atau jumlah diskaun telah meninggalkan jurang keselamatan dan ketepatan.
Isyarat kedua ialah pemulihan, bukan sekadar pengesanan. Sempadan tidak sah adalah tidak mencukupi. Setiap ralat memerlukan teks biasa, hubungan programatik dengan kawalannya, dan arahan pembetulan. Semasa penyerahan, pengguna memerlukan gambaran keseluruhan dan tempat yang boleh diramal untuk fokus. Input mereka yang sah mesti kekal utuh.
Isyarat ketiga ialah pemasaan. Menunjukkan "tidak sah" semasa pengguna masih menaip e-mel mewujudkan gangguan. Lakukan pengesahan semasa serahan (submit) terlebih dahulu; selepas sesuatu medan gagal, sahkan semula semasa blur atau perubahan yang bermakna supaya pengguna dapat melihat bahawa pembetulan telah berjaya. Pengesahan tak segerak memerlukan keadaan belum selesai (pending) dan perlindungan respons lapuk (stale response).
Isyarat terakhir ialah pengesahan (verification). Imbasan kebolehcapaian automatik boleh mencari label yang hilang, tetapi tidak dapat membuktikan kewajaran pengumuman, susunan fokus, pemulihan selepas respons pelayan, atau perlindungan daripada respons kod diskaun yang tidak mengikut urutan. Perkara tersebut memerlukan ujian interaksi.
Soalan untuk Dijelaskan Sebelum Menjawab
- Semakan manakah yang bersifat tempatan? Kehadiran nilai, format, dan peraturan mudah rentas medan boleh dijalankan secara tempatan. Harga, stok, kelayakan, dan kesahihan akhir diskaun adalah hak milik pelayan.
- Bilakah maklum balas patut muncul? Serahan mendedahkan semua ralat yang menyekat. Medan yang telah gagal boleh disahkan semula semasa blur atau selepas perubahan yang disengajakan; jangan buat pengumuman pada setiap ketukan kekunci.
- Adakah pelayan akan merender semula halaman? Kedua-dua penyerahan borang yang dipertingkatkan dan biasa mesti mengekalkan nilai serta merender ralat berstruktur yang sama.
- Bolehkah satu ralat menjejaskan beberapa kawalan? Negara dan poskod membentuk satu peraturan. Letakkan arahan yang dikongsi berdekatan kumpulan tersebut dan pautkan ringkasan kepada kawalan yang memulakan pembetulan.
- Apakah yang berlaku semasa pengesahan diskaun? Keadaan pending adalah bermaklumat, bukan ralat. Nilai semasa dan generasi permintaan menentukan sama ada sesuatu respons masih relevan.
- Ke manakah fokus harus beralih selepas kegagalan? Untuk beberapa ralat, fokuskan ringkasan sebelum borang; untuk kes ralat tunggal yang padat, memfokuskan kawalan yang tidak sah boleh diterima. Pilih satu dasar dan elakkan daripada mengumumkan perubahan yang sama dua kali.
- Kegagalan manakah yang bukan ralat medan? Gangguan rangkaian atau perubahan stok tergolong dalam mesej peringkat borang dengan laluan cuba semula. Jangan sambungkannya kepada e-mel atau poskod.
- Adakah aliran ini mendedahkan fakta sensitif? Borang pengesahan dan pemulihan akaun mungkin memerlukan mesej pelayan yang generik. Pembetulan yang membantu tidak boleh mendedahkan sama ada sesuatu akaun wujud.
Rangka Jawapan 30 Saat
“Saya bermula dengan kawalan natif berlabel dan kekangan, tetapi pelayan kekal berautoriti. Setiap kawalan tidak sah menerima aria-invalid="true" dan ralat teks stabil yang dirujuk oleh aria-describedby; warna dan ikon adalah sekunder. Penyerahan gagal yang pertama merender ringkasan ralat dengan pautan ke setiap medan tidak sah dan mengalihkan fokus ke ringkasan tersebut. Nilai yang dimasukkan kekal di tempatnya.
Saya mengesahkan semasa serahan, kemudian semasa blur atau perubahan bermakna hanya untuk medan yang telah gagal. Semakan kod diskaun menggunakan debounce, boleh dibatalkan, dan ditag dengan generasi supaya respons lama tidak boleh menggantikan nilai baharu. Pelayan mengembalikan ralat medan yang diketahui serta ralat peringkat borang dalam bentuk berstruktur. Saya menguji pemulihan papan kekunci dan pembaca skrin, zum dan forced colors, round trip pelayan, penyerahan tanpa JavaScript, dan async race di samping semakan automatik.”
Perbincangan Mendalam Langkah demi Langkah
Langkah 1: Tentukan keadaan dan invarian
Asingkan nilai daripada keadaan pengesahan. Setiap medan boleh berada dalam keadaan belum disentuh (untouched), belum selesai (pending), sah (valid), atau tidak sah (invalid), dengan kod ralat yang dipetakan kepada teks setempat. Ralat peringkat borang adalah berasingan. Simpan bendera percubaan penyerahan supaya UI tidak memaparkan medan yang ditaip separuh jalan sebagai gagal.
Invariannya ialah: label kekal kelihatan; arahan wujud sebelum ralat; setiap ralat medan yang dipaparkan dikaitkan secara programatik; ralat tersembunyi tidak dirujuk; satu penyerahan menghasilkan satu peralihan fokus yang jelas; input yang sah kekal wujud semasa kegagalan; dan respons tak segerak yang lapuk tidak boleh mengubah keadaan semasa.
Langkah 2: Bina kawalan semantik sebelum ARIA
Gunakan label, jenis input yang paling khusus, required, autocomplete, dan kekangan panjang atau corak yang sesuai. Peraturan poskod yang bergantung pada negara boleh menggunakan setCustomValidity(). Kosongkan mesej tersuai dengan rentetan kosong sebaik sahaja nilai menjadi sah; jika tidak, pelayar akan terus menyekat penyerahan.
<label for="email">Email</label>
<input id="email" name="email" type="email"
aria-invalid="true"
aria-describedby="email-hint email-error">
<p id="email-hint">name@example.com</p>
<p id="email-error">Enter a valid email address.</p>checkValidity() menyemak kekangan, manakala reportValidity() turut meminta pelayar membentangkan maklum balasnya. Jika produk merender mesej boleh diaksesnya sendiri, pintas keadaan tidak sah secara konsisten dan bukannya memaparkan dua sistem ralat yang bersaing.
Langkah 3: Pilih pemasaan pengesahan secara sengaja
Pada penyerahan pertama, sahkan setiap medan dan dedahkan semua ralat yang menyekat. Selepas itu, sahkan semula medan yang tidak sah semasa blur. Bagi pilihan atau nilai yang dibetulkan dengan bentuk lengkap yang jelas, perubahan boleh mengosongkan ralat dengan lebih awal. Jangan hantar pengumuman live-region secara berulang kali semasa tarikh atau e-mel belum lengkap.
Peraturan rentas medan dijalankan apabila mana-mana kebergantungan berubah. Jika negara berubah, sahkan semula poskod dan kemas kini arahan yang kelihatan. Jangan tulis semula input pengguna secara senyap-senyap melainkan penyeragaman tersebut selamat dan boleh diterbalikkan; memangkas ruang putih di sekeliling adalah berbeza daripada meneka format poskod.
Langkah 4: Kemukakan ralat sebaris dan ringkasan yang boleh dinavigasi
Render teks ringkas di sebelah setiap medan, tetapkan aria-invalid hanya semasa tidak sah, dan rujuk ID stabil bagi ralat tersebut. Pastikan penampilan visual boleh digunakan dalam mod forced-colors dan sertakan perkataan, bukan hanya sempadan merah atau ikon amaran.
Selepas penyerahan pelbagai ralat gagal, sisipkan ringkasan bertajuk sebelum borang. Berikan sasaran fokus sementara, fokuskan sekali, nyatakan bilangan ralat, dan sediakan pautan ke kawalan berkaitan. Teks pautan hendaklah menamakan medan dan pembetulan. Jangan alihkan juga fokus ke medan pertama dalam peristiwa yang sama; tindakan itu akan menyukarkan ringkasan untuk diperiksa.
Langkah 5: Jadikan pengesahan tak segerak selamat daripada race condition
Tunggu sehingga kod diskaun lengkap, kemudian gunakan debounce pada permintaan. Batalkan (abort) permintaan sebelumnya apabila nilai berubah dan bandingkan juga generasi yang meningkat secara monoton semasa selesai. Kedua-dua semakan adalah penting kerana pembatalan boleh tiba selepas respons telah pun diproses.
Tunjukkan status “Menyemak” berhampiran melalui polite live region. Lumpuhkan tindakan menggunakan diskaun semasa semakan belum selesai, tetapi jangan lumpuhkan medan lain yang tidak berkaitan. Masa tamat (timeout) menjadi status peringkat borang atau peringkat kod yang boleh dicuba semula mengikut kontrak produk; ia tidak boleh dilaporkan sebagai “kod tidak sah”. Simpan hasil cache hanya dengan konteks harga dan tempoh luput yang menjadikannya sah.
Langkah 6: Selaraskan ralat pelayan yang berautoriti
Serahkan nilai mentah melalui tindakan borang biasa atau permintaan yang dipertingkatkan. Pelayan menormalkan dan mengesahkan semula, mengira jumlah keseluruhan, dan mengembalikan hasil seperti kod ralat medan, kod ralat borang, dan nilai yang diterima. Klien memetakan nama medan yang dibenarkan sahaja. Kunci yang tidak diketahui menjadi ralat peringkat borang yang selamat dan bukannya peluang suntikan pemilih atau markup.
Sekiranya ditolak, kekalkan semua entri yang tidak sensitif, gantikan tekaan klien dengan kebenaran pelayan, render ringkasan yang sama, dan fokuskan kepadanya. Jika berjaya, tunjukkan pengesahan yang jelas dan elakkan pengaktifan pendua. Sekiranya respons hilang selepas penyerahan, gunakan kunci kedap sesekali (idempotency key) atau carian pesanan sebelum menggalakkan caj lain.
Langkah 7: Sahkan laluan pemulihan, bukan snapshot
Uji penyerahan kosong, satu ralat, beberapa ralat, kebergantungan negara/poskod, tarikh penghantaran tamat tempoh, masa tamat diskaun, diskaun tidak sah, perubahan kod yang pantas, penolakan pelayan sahaja, dan respons kejayaan yang hilang. Pastikan nilai kekal, pautan ringkasan memfokuskan kawalan yang betul, ralat yang dibetulkan hilang, dan respons tak segerak yang lama diabaikan.
Lengkapkan aliran secara manual menggunakan papan kekunci sahaja dan pembaca skrin. Semak zum 200%, pengaliran semula (reflow), fokus kelihatan, forced colors, autolengkap pelayar, dan penyerahan pelayan biasa tanpa JavaScript klien. Ujian kebolehcapaian automatik dan ujian unit melengkapkan semakan ini; ujian tersebut tidak menggantikan ujian pengumuman dan fokus.
Contoh Jawapan yang Mantap
“Saya akan memodelkan nilai medan secara berasingan daripada keadaan disentuh, belum selesai, dan ralat. Label natif, jenis input, token autolengkap, dan kekangan membekalkan garis asas. Peraturan rentas medan tersuai menggunakan setCustomValidity() dan sentiasa mengosongkan mesej apabila sah. Semakan klien meningkatkan kelajuan; pelayan mengesahkan semula harga, stok, alamat, dan diskaun sebelum menerima pesanan.
Penyerahan pertama mendedahkan setiap ralat yang menyekat. Setiap input tidak sah menerima aria-invalid="true" dan merujuk teks pembetulan yang kelihatan dengan aria-describedby. Bagi ralat berganda, saya merender ringkasan sebelum borang, memfokuskannya sekali, dan memautkan setiap item kepada kawalannya. Nilai yang sah kekal tidak berubah. Selepas penyerahan tersebut, medan yang gagal disahkan semula semasa blur atau perubahan bermakna, tanpa pengumuman langsung pada setiap ketukan kekunci.
Pengesahan diskaun menggunakan debounce dan membawa isyarat batalkan serta nombor generasi. Hanya respons yang sepadan dengan nilai semasa boleh mengemas kini UI. Keadaan belum selesai dan tidak tersedia dibezakan daripada tidak sah. Kod medan pelayan dipetakan melalui senarai yang dibenarkan; kegagalan global kekal pada peringkat borang. Saya hanya akan melancarkannya selepas ujian papan kekunci, pembaca skrin, zum, round trip pelayan tanpa skrip, race condition, dan penyerahan pendua lulus di samping semakan automatik.”
Kesilapan Biasa
- Menggunakan sempadan merah sahaja → sesetengah pengguna tidak dapat melihat keadaan tersebut → tambah teks pembetulan, perkaitan programatik, dan pembayang bukan warna.
- Mengesahkan setiap ketukan kekunci → input yang tidak lengkap mewujudkan gangguan berterusan → sahkan semasa serahan, kemudian sahkan semula medan yang gagal pada sempadan yang berguna.
- Membiarkan
setCustomValidity()terisi → input yang dibetulkan kekal tidak sah → tetapkannya kepada rentetan kosong apabila peraturan dipenuhi. - Memfokuskan ringkasan dan medan pertama serentak → pengumuman dan fokus bersaing → buat satu pergerakan fokus yang disengajakan dan sediakan pautan untuk navigasi.
- Menganggap masa tamat sebagai kod tidak sah → kegagalan infrastruktur menjadi kesalahan palsu yang diletakkan pada pengguna → wakili status belum selesai, tidak tersedia, dan tidak sah secara berasingan.
- Menerima respons terakhir yang diterima → pengesahan lapuk menimpa input semasa → batalkan kerja lama dan bandingkan generasi permintaan.
- Mempercayai jumlah harga pada klien → permintaan boleh memintas UI → kira semula dan sahkan pada pelayan.
- Mengosongkan borang selepas kegagalan → pemulihan menjadi kemasukan semula dari awal → kekalkan nilai sah yang tidak sensitif dan gantikan keadaan ralat sahaja.
Soalan dan Jawapan Susulan
Soalan Susulan 1: Patutkah ringkasan menggunakan role="alert"?
Untuk ralat yang disisipkan secara dinamik, alert atau live region yang sesuai boleh mengumumkan ringkasan tersebut. Fokus juga boleh menjadikannya tersedia. Uji gabungan yang dipilih kerana fokus ditambah alert yang tegas (assertive) boleh mengumumkan kandungan yang sama dua kali. Pada navigasi pelayan penuh, meletakkan jumlah ralat dalam tajuk halaman dan tajuk utama boleh memberikan konteks yang lebih awal.
Soalan Susulan 2: Mengapakah tidak melumpuhkan butang serah sehingga borang menjadi sah?
Butang yang dilumpuhkan boleh menyembunyikan perkara yang masih salah dan tidak boleh dicapai oleh sesetengah mod navigasi. Kekalkan laluan serahan tersedia supaya pengguna boleh meminta hasil pengesahan yang lengkap. Lumpuhkan hanya semasa penyerahan sebenar sedang berjalan, jelaskan keadaan tersebut, dan pulihkan jika ia gagal.
Soalan Susulan 3: Bilakah aria-describedby lebih diutamakan berbanding live region?
aria-describedby memberikan petunjuk dan ralat semasa bagi medan tersebut apabila pengguna mencapainya. Live region mengumumkan perubahan dinamik yang bermakna tanpa fokus. Ralat sebaris yang statik tidak semuanya memerlukan live region; mengumumkan setiap medan secara serentak adalah bising. Gunakan ringkasan untuk kelompok ralat dan status sopan (polite) untuk perubahan yang benar-benar tak segerak.
Soalan Susulan 4: Bagaimanakah anda menyokong pengesahan yang dirender pelayan tanpa JavaScript?
Gunakan tindakan borang yang sebenar. Pelayan mengembalikan halaman yang sama dengan nilai yang dikekalkan, kod ralat medan, ringkasan sebelum borang, dan kiraan ralat dalam tajuk halaman atau tajuk utama. Pautan ringkasan menggunakan ID kawalan yang stabil. Peningkatan pada klien harus menggunakan kontrak ralat yang sama, supaya kedua-dua mod tidak terpesong antara satu sama lain.
Soalan Susulan 5: Bagaimanakah anda menguji async race secara deterministik?
Kawal dua Promise pengesahan. Mulakan permintaan A, tukar nilai, kemudian mulakan B. Selesaikan B sebagai sah dan A kemudiannya sebagai tidak sah. Pastikan UI masih mencerminkan B dan nilai semasa. Ulangi dengan pembatalan (abort), masa tamat (timeout), unmount, dan penyerahan semula semasa masih belum selesai.