Description
I'd like to preface this with the simple fact that this is SUCH an easy and straightforward issue that no jsfiddle needs to be provided, it's literally 3 lines of code that are probably the easiest 3 lines to read in the whole repo, so I'm just going to explain my issue and my rather plain way of resolving it...
As a developer
I want to have my zipcode validated for my state when I change the state
so that I can guarantee my data is valid
To do this, I wrote a custom remote rule:
$("#zipcode").rules("add", { //when entering zipcode, check if is valid in state
"remote": {
url: "zipcodeApiUrl",
type: "GET",
data: {
stateAbbreviation: function () {
return $("#state").val(); //send state code
}
}
}
});
$("state").on("change", function () { //when changing state
$("zipcode").valid(); //then check if zipcode is valid
});
The offending line is 1320-1322 inside of the remote property of jquery.validate.js:
if ( previous.old === value ) {
return previous.valid;
}
So I change my state from NY to OK but leave the zipcode (11735) in place, the first call to the api endpoint returns a bad validation result for OK and 11735 - perfect!
But then I realize I changed the state by mistake, so I go back and change it to NY...
But it tells me that the validation is still failing... for OK!
I suppose this is to reduce the number of calls to remote apis when the form is being validated.
I would have sent up a patch for this, but that would really just have been me deleting lines 1320,1321, and 1322 :). However, this occurs to me as a breaking change that would (possibly) disrupt other people's workflow, in addition possibly adding an inefficiency.
If it were me, I'd just add an additional option for "perform check always" to the remote option (defaulted to false, of course), which I will do if someone gives me some positive feedback on this solution.
So if anyone would like to outline another option, or if the repo owner could give me a nudge in the right direction, I will go ahead and do it gladly (following the contrib guidelines), but I wanted to get some consensus before I go knocking down doors, especially since I can identify a clear use case in both directions.