Ini mungkin tidak langsung menjawab pertanyaan Anda, tetapi masalah ini bisa diselesaikan dengan penyesuaian tingkat desain sederhana. Saya memahami ini mungkin tidak 100% berlaku untuk semua kasus penggunaan, tetapi saya sangat menyarankan Anda untuk mempertimbangkan kembali aliran pengguna aplikasi Anda dan jika saran desain berikut dapat diterapkan.
Saya memutuskan untuk melakukan sesuatu yang sederhana dari hacking alternatif untuk onChange()
menggunakan peristiwa lain yang tidak benar-benar dimaksudkan untuk tujuan ini ( blur
, click
, dll)
Cara saya menyelesaikannya:
Cukup pra-tunda tag opsi placeholder seperti pilih yang tidak memiliki nilai untuk itu.
Jadi, alih-alih hanya menggunakan struktur berikut, yang membutuhkan alternatif hack-y:
<select>
<option>A</option>
<option>B</option>
<option>C</option>
</select>
Pertimbangkan untuk menggunakan ini:
<select>
<option selected="selected">Select...</option>
<option>A</option>
<option>B</option>
<option>C</option>
</select>
Jadi, dengan cara ini, kode Anda BANYAK lebih disederhanakan dan onChange
akan berfungsi seperti yang diharapkan, setiap kali pengguna memutuskan untuk memilih sesuatu selain nilai default. Anda bahkan dapat menambahkan disabled
atribut ke opsi pertama jika Anda tidak ingin mereka memilihnya lagi dan memaksa mereka untuk memilih sesuatu dari opsi, sehingga memicu onChange()
kebakaran.
Pada saat jawaban ini, saya sedang menulis aplikasi Vue yang kompleks dan saya menemukan bahwa pilihan desain ini telah banyak menyederhanakan kode saya. Saya menghabiskan berjam-jam untuk masalah ini sebelum saya menyelesaikan dengan solusi ini dan saya tidak perlu menulis ulang banyak kode saya. Namun, jika saya menggunakan alternatif peretasan, saya harus memperhitungkan kasus tepi, untuk mencegah penembakan ganda atas permintaan ajax, dll. Ini juga tidak mengacaukan perilaku peramban default sebagai bonus bagus (diuji pada ponsel browser juga).
Terkadang, Anda hanya perlu mengambil langkah mundur dan memikirkan gambaran besar untuk solusi paling sederhana.