A search box can display the wrong results even when every HTTP request succeeds. A player types sword, then changes the query to shield. If the first request finishes last, an unguarded callback replaces the shield results with swords.

Use an AbortController to cancel obsolete network work and a request ID to decide which result may update the interface. This example targets browser pages, including Cocos Creator Web builds with the required browser APIs. Check API support separately before adapting it to a native game runtime.

Why completion order is different from input order

Consider two overlapping requests:

Rendering every response makes the interface end with the wrong query’s data. Debouncing reduces how often requests start, but requests can still overlap when a user pauses between edits.

Cancellation and rendering permission solve different parts of the problem. Cancellation asks an operation to stop. The request ID records which input still owns the view, including when a mock, wrapper, or later asynchronous step does not honor cancellation.

Keep one owner for each search view

Create one search controller per view. The endpoint in this example is a placeholder for your own same-origin API. It accepts a q query parameter and returns a JSON array of item names, such as ["Iron Shield", "Wooden Shield"].

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

function createSearch(onState) {
  let requestId = 0;
  let activeController = null;
  let disposed = false;

  async function search(rawQuery) {
    if (disposed) return;

    const id = ++requestId;
    activeController?.abort();
    activeController = null;
    const query = rawQuery.trim();

    if (!query) {
      onState({ status: "idle", items: [] });
      return;
    }

    const controller = new AbortController();
    activeController = controller;
    onState({ status: "loading", items: [] });

    try {
      const params = new URLSearchParams({ q: query });
      const response = await fetch(`/api/items?${params}`, {
        signal: controller.signal,
      });
      if (!response.ok) {
        throw new Error(`HTTP ${response.status}`);
      }

      const items = await response.json();
      if (!Array.isArray(items) ||
          !items.every((item) => typeof item === "string")) {
        throw new Error("Expected an array of item names");
      }

      if (disposed || id !== requestId || controller.signal.aborted) return;
      onState({ status: "success", items });
    } catch (error) {
      if (disposed || id !== requestId || controller.signal.aborted) return;
      onState({
        status: "error",
        items: [],
        message: error instanceof Error ? error.message : String(error),
      });
    } finally {
      if (id === requestId) activeController = null;
    }
  }

  function dispose() {
    disposed = true;
    ++requestId;
    activeController?.abort();
    activeController = null;
  }

  return { search, dispose };
}

The ID changes before aborting the old request. Its eventual success or failure therefore cannot publish state for the new query. Clearing the input also increments the ID and aborts the active request before emitting the idle state.

Keep the ownership check after the final await and immediately before updating the view. If you later add asynchronous filtering or another lookup, move the check after that work as well. Apply the same check in catch; otherwise an obsolete error can replace a successful newer result.

The finally block releases only the controller belonging to the latest request. An older request finishing must not erase the reference needed to cancel a newer one. Loading state is emitted explicitly, so an old finally block cannot turn off the newer request’s loading indicator.

Connect the controller to a browser interface

Place this markup in the page, then run the following script after the elements exist and after defining createSearch:

1
2
3
4

<label for="item-query">Find an item</label>
<input id="item-query" type="search" autocomplete="off">
<p id="search-status" role="status"></p>
<ul id="search-results"></ul>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

const input = document.querySelector("#item-query");
const status = document.querySelector("#search-status");
const results = document.querySelector("#search-results");

const searchView = createSearch((state) => {
  results.replaceChildren();
  status.textContent = state.status === "loading" ? "Searching..."
    : state.status === "error" ? `Search failed: ${state.message}`
    : state.status === "success" ? `${state.items.length} items found`
    : "";

  for (const name of state.items) {
    const item = document.createElement("li");
    item.textContent = name;
    results.append(item);
  }
});

function onInput() {
  void searchView.search(input.value);
}

input.addEventListener("input", onInput);

function unmountSearchView() {
  input.removeEventListener("input", onInput);
  searchView.dispose();
}

Call unmountSearchView() from your router or view teardown before removing the interface. Create a new controller if the view opens again. The renderer is synchronous and should not throw; keep component validity checks in your own renderer if the framework can destroy its targets independently.

Use textContent for names returned by the server so they are displayed as text. Replace the DOM rendering with your game UI updates when adapting the ownership pattern to a Cocos Web scene.

What aborting a request guarantees

A new request gets a new controller because an aborted signal stays aborted. Passing that signal to fetch connects cancellation to the request and response body consumption. A response can arrive before its body has finished being read, so keep response.json() inside the same try block. See the DOM Standard’s abort definitions and MDN’s abort documentation .

HTTP failures still require an explicit response.ok check, and valid JSON still needs validation against the application’s expected shape. These are separate from cancellation; MDN’s Fetch guide explains response handling.

Aborting the client request does not provide a server-side rollback guarantee. Use this pattern for replaceable reads. For purchases or other writes, enforce correctness on the server even if the user leaves the view.

Verify the race and cleanup paths

Test with controlled response ordering, not only a fast local server:

1. Start sword, then shield. Resolve shield first and sword last. The final state must contain only shield results. Use a mock that ignores the abort signal to exercise the ID check independently.
2. Reject the old request after the new request succeeds. The newer results must stay visible without an error message.
3. Clear the input while a request is pending. Resolve it afterward. The view must remain idle and empty.
4. Dispose the view while fetching or reading JSON. No later state callback should run.
5. Return an HTTP 500 response, malformed JSON, and a JSON object instead of an array for the current request. Each should produce an error state.

If a debounce timer is added later, invalidate the active request as soon as the input changes, before waiting for the timer. Otherwise results for the previous query can still appear during the debounce interval.