Cela peut ne pas répondre directement à votre question, mais ce problème peut être résolu par de simples ajustements au niveau de la conception. Je comprends que cela peut ne pas être applicable à 100% à tous les cas d'utilisation, mais je vous exhorte fortement à envisager de repenser votre flux d'utilisateurs de votre application et si la suggestion de conception suivante peut être mise en œuvre.
J'ai décidé de faire quelque chose de simple que les alternatives de piratage pour l' onChange()
utilisation d' autres événements qui ne sont pas vraiment destinés à cet effet ( blur
, click
, etc.)
La façon dont je l'ai résolu:
Préparez simplement une balise d'option d'espace réservé, telle que select, qui n'a aucune valeur.
Ainsi, au lieu d'utiliser simplement la structure suivante, qui nécessite des alternatives de piratage:
<select>
<option>A</option>
<option>B</option>
<option>C</option>
</select>
Pensez à utiliser ceci:
<select>
<option selected="selected">Select...</option>
<option>A</option>
<option>B</option>
<option>C</option>
</select>
Ainsi, de cette façon, votre code est beaucoup plus simplifié et onChange
fonctionnera comme prévu, chaque fois que l'utilisateur décide de sélectionner autre chose que la valeur par défaut. Vous pouvez même ajouter l' disabled
attribut à la première option si vous ne voulez pas qu'ils le sélectionnent à nouveau et les forcer à sélectionner quelque chose dans les options, déclenchant ainsi un onChange()
incendie.
Au moment de cette réponse, j'écris une application Vue complexe et j'ai trouvé que ce choix de conception a beaucoup simplifié mon code. J'ai passé des heures sur ce problème avant de m'installer avec cette solution et je n'ai pas eu à réécrire beaucoup de mon code. Cependant, si je suis allé avec les alternatives hacky, j'aurais dû tenir compte des cas de bord, pour éviter le double tir des demandes ajax, etc. navigateurs également).
Parfois, il vous suffit de prendre du recul et de penser à la situation dans son ensemble pour la solution la plus simple.