Make the revision explicit

Keep a small state contract alongside the field value:

Field state Meaning
value The text the operator currently sees and edits.
revision A monotonic value changed whenever that text changes.
requestRevision The revision captured when validation begins.
status idle, pending, valid, or invalid for the current value only.

When the value changes, increment revision, clear a prior validation message, and make old results ineligible. When the response returns, apply it only if its revision equals both the current revision and the request revision. This is a client rendering rule; the server must still validate and authorize submitted data.

Do not turn an old result into current feedback

An older success is just as stale as an older failure. If the value changed after the request started, keep the new field idle or start a new validation request. Do not show “available” for a value the server never checked.

The following framework-independent model makes the acceptance rule inspectable:

function receiveValidation(state, result) {
  if (result.revision !== state.revision || result.revision !== state.requestRevision) {
    return state; // An old answer cannot describe the current value.
  }
  return {
    ...state,
    status: result.valid ? "valid" : "invalid",
    message: result.valid ? null : result.message,
  };
}

The local model tests current success, current failure, stale success, stale failure, and a new request after an edit:

npm test --prefix sites/reactjsx.com/evidence/P104

It is intentionally independent of JSX and a form library. Connect it to the application's debouncing, request cancellation, error messages, and server contract without assuming any one library exposes the same lifecycle.

Keep status understandable

While a current request is pending, show that the current value is being checked. On a current invalid result, associate the visible message with the field and make a correction possible. On a stale result, do not announce it as current status. The accessibility implementation should be reviewed in the target browser and assistive-technology combinations.

This rule does not cancel a network request, prevent every race, or prove the input is permitted. It prevents one narrow interface error: an older answer overwriting the status for a newer value.

Is aborting the old request enough?

No. Abortion can reduce unnecessary work, but the rendering rule should still reject a result that does not belong to the current revision.

Can client validation replace server validation?

No. Client validation improves feedback. The trusted service must validate the submitted value and enforce any authorization or uniqueness rule.