A parts catalogue suggests matches while a customer types. The customer enters a short code, adds two more characters, and sees the right result appear. A moment later, the list changes back to matches for the shorter code. The page has avoided a reload, but it has displayed the wrong answer to the customer's latest request.

This is the kind of problem an AJAX implementation must handle. AJAX means Asynchronous JavaScript and XML, but the technique does not require XML. As described in MDN's AJAX overview, JavaScript can request content and update part of a page without loading a complete new document. The engineering work includes deciding which response still belongs on the screen.

A request and a page update are separate steps

A search interaction usually has several stages: capture the current query, send it to an endpoint, interpret the response, and update the results area. JSON is a common response format, and text or HTML can also be used. AJAX names the overall approach, rather than a particular framework, server language, or mandatory collection of page technologies.

The browser can remain available for other interaction while the network request is pending. That does not make server work instantaneous or move the application's important business rules into the browser. An expensive database search can still be expensive, and sending a request for every keystroke can create unnecessary work.

For the parts catalogue, consider waiting briefly after typing pauses before requesting suggestions. Choose that behavior by testing how people enter codes, including pasted values and corrections. The aim is to reduce pointless requests while keeping the interaction useful, not to impose a universal delay on every search box.

Decide which result is allowed to update the screen

Requests do not have to finish in the order they were started. The first search might take longer than the second. If the application displays every completed response unconditionally, an older answer can replace the newer one.

Associate each request with the search state that produced it. Before rendering the result, check that the request still represents the current interaction. A sequence identifier can distinguish successive requests even when a user returns to text entered earlier. Discarding an obsolete result is different from treating it as an application error.

MDN's Fetch guide explains how AbortController can cancel a fetch request. Cancellation can help when a search is superseded, but the application should still control which response may update the interface. Cancellation also should not be presented to users as a guarantee that an already submitted server-side change has been undone.

Handle HTTP errors and unusable responses

The same Fetch guide notes that an HTTP error such as a 404 does not automatically reject the fetch promise. Check the response status as well as handling network failure. Reading the response body is another step, and JSON parsing can fail if the returned content is not valid JSON.

Then verify that the data has the shape the feature expects. A successful HTTP status with an unexpected payload is not a usable parts list. Keep diagnostic detail for maintainers while giving the customer a clear message and a sensible next action.

Make waiting, empty results, and failure distinguishable

An empty results area is ambiguous. It might mean the search has not started, is still running, found nothing, or failed. Give these states deliberate behavior. Keep the entered code available after failure, and offer a retry or ordinary search submission where the application supports it.

W3C's status-message guidance explains that relevant status messages should be available to assistive technology without requiring focus to move to them. A concise completion or waiting message is different from announcing the entire results list after every update. The guidance also warns against unnecessarily chatty feedback.

Preserve a predictable keyboard path through the search and results. A refresh should not steal focus from someone who is still typing. Test the real interaction with keyboard and screen-reader use, because a visible spinner and a changing list do not establish that everyone understands what happened.

Give important searches a recoverable state

If customers need to share or return to a filtered result, define how the application represents that search in a URL. Test opening it directly, refreshing, and using Back after changing filters. Temporary suggestions and a committed search need not create identical navigation history. Choose behavior that matches the customer's task and verify it explicitly.

Keep the endpoint responsible for trusted decisions

An AJAX endpoint can be called independently of the page that normally uses it. OWASP's AJAX security guidance therefore emphasizes server-side validation and business rules. Hiding a button or filtering a browser list does not authorize a user to view or change the underlying record.

For a parts catalogue with account-specific information, check access on the server for the requested records. When the interaction changes stored information, apply the application's appropriate request-forgery protections. Treat returned content carefully too: plain part descriptions should be inserted as text, rather than interpreted as untrusted HTML.

Finish testing with cases that a fast local connection can conceal: rapid query changes, a slow response, a dropped connection, an expired session, no matches, and a retry. The useful improvement is a search that stays coherent through those conditions. Removing the full-page reload is only one part of that result.