The example below reserves a fictional equipment pickup code. It illustrates a read-only availability check followed by a separate submit route. You must supply both endpoints; the fragment does not create a backend.
Give the field a name before adding a rule
Load your supported jQuery build before the validation plugin, then run initialization after the form exists. Preserve the application's existing dependency and asset management.
<form id="pickup" action="/pickups" method="post">
<label for="pickup-code">Pickup code</label>
<input id="pickup-code" name="pickupCode"
type="text" required minlength="4">
<p>Use the code supplied by the equipment desk.</p>
<button type="submit">Reserve pickup</button>
</form>
The label uses the input's id. Plugin rules use its name. A rule keyed as pickup-code would not address the pickupCode field shown here. Add the application's CSRF field or equivalent protection to the real POST form.
$('#pickup').validate({
errorElement: 'span',
rules: {
pickupCode: {
required: true,
minlength: 4,
remote: {
url: '/pickups/code-available',
type: 'get'
}
}
},
messages: {
pickupCode: {
required: 'Enter your pickup code.',
remote: 'That code is already reserved.'
}
}
});
The plugin associates its non-label error element with the field through aria-describedby. Keep the original visible label, and check the resulting message next to the actual form. Accessibility guidance
Return the response shape the remote rule expects
For this field, the default remote request includes pickupCode and its current value. The endpoint should return JSON. A useful contract is:
Available: true
Unavailable: false
These are JSON booleans, not an object such as {"available":true}. The current plugin also accepts the JSON string "true" as a valid response. An unavailable response can be a JSON message string, but a fixed message in the form avoids sending server-generated HTML into an error message. Remote response handling in the official source
A login page returned with HTTP 200 is not a successful availability response. If the form remains pending, inspect the Network panel: confirm the expected parameter, response body, content type, and authentication behavior. A timeout or server error needs a visible retry path in the application's error handling; it is not evidence that the code is available.
Let the plugin manage submission while the request is pending
The current plugin's submit handler tracks pending remote requests. Do not add a second click handler that immediately sends the booking regardless of that pending state. With the ordinary form above, allow the plugin-controlled form submission to continue once validation succeeds. Submission and pending-request implementation
If the application uses AJAX submission, place that integration in the plugin's submitHandler and preserve the application's error and duplicate-submission handling. Do not call $(form).submit() from inside that handler, which reenters the submit event.
Availability can change between the remote check and submission. The server handling /pickups must validate the incoming value and enforce the actual reservation constraint. The earlier GET check gives the reader feedback; it does not reserve a code.
Verify the failure and success paths
In development, submit an empty code and a code shorter than four characters. Those should fail locally. Then use one known available fixture and one unavailable fixture, checking the request and displayed response. Delay the availability endpoint and submit while it is pending; verify that the booking is not sent early. Finally, simulate a failed endpoint and confirm the form explains how to retry.
For forms that only need presence, length, or a basic input shape, native HTML validation may already cover the task. Use the plugin where the existing jQuery application needs its message handling and remote lifecycle, and finish by confirming that a conflicting reservation is rejected by the final submit route.