How can a component avoid updating its state after it has been removed?

Pair the operation with cleanup. Cleanup should either cancel work that supports cancellation or mark its result as no longer eligible to update the component. If cancellation is unavailable, an active flag is a simple guard. This plain JavaScript sketch assumes startWork() returns a promise, applyResult() updates the component, and reportError() handles genuine failures:

let active = true;

startWork()
  .then(result => {
    if (active) applyResult(result);
  })
  .catch(error => {
    if (active) reportError(error);
  });

function cleanup() {
  active = false;
}

Call cleanup() when the component is removed. The flag does not stop startWork(); it only prevents this code from applying a late result or reporting its error after cleanup. Replace the placeholder functions with your component’s actual operation and update logic.

Yes, when the request API supports cancellation. For Microsoft Power Pages, its client API documentation shows creating an AbortController, passing its signal to a request, and calling abort() from cleanup. It also says an aborted request rejects with a cancellation error, which the example distinguishes from other errors. This is specific to that product’s client API; it does not establish that other frameworks, requests, or asynchronous operations use the same interface. [S1]

The shape of that example is:

const controller = new AbortController();

startSupportedRequest({ signal: controller.signal })
  .then(result => applyResult(result))
  .catch(error => {
    if (isCancellation(error)) return;
    reportError(error);
  });

function cleanup() {
  controller.abort();
}

Here, startSupportedRequest() and isCancellation() are placeholders, not a claim about a particular API’s method names or error shape. Use the request API’s documentation to supply those details. If the operation cannot be canceled, keep the active-result check as a guard.

Treat cleanup as the point after which this component must not apply results. Set the active flag to false in cleanup, and check it immediately before every component update that depends on the asynchronous result. If the work has multiple steps that each update the component, guard each update—not just the first one. Also decide whether an error that arrives after removal should be ignored, logged elsewhere, or handled by a longer-lived owner; do not accidentally treat every failure as cancellation.

If both cancellation and a guard are available, the two serve different purposes in your code: request cancellation asks supported work to stop, while the guard blocks a result from being applied after cleanup. Neither pattern undoes an update that already happened. Make cleanup safe to call according to your framework’s lifecycle rules, and avoid letting an older operation overwrite a newer result if the component remains mounted and starts overlapping work.

Use your framework’s documented setup and cleanup hooks; the example below is framework-neutral rather than a framework lifecycle recipe. Suppose a search starts for "maple", then the component is removed before the result returns. Cleanup marks that search inactive. When its result arrives, the active check skips applyResults(result). If the request API supports cancellation, cleanup can also ask it to stop the request; use that API’s own cancellation and error-handling conventions.

A reusable adaptation checklist:

1. Identify the exact operation that may outlive the component, and whether its API supports cancellation.
2. Create a controller or active flag for that operation when it starts.
3. Register cleanup using the component’s documented removal or disposal mechanism.
4. In cleanup, cancel supported work and/or mark the result inactive.
5. Check the guard before every component update; handle cancellation separately from real errors.
6. Test the timing where removal happens before completion, and the timing where completion happens first.

This protects against late updates; it is not a substitute for the framework’s lifecycle documentation or the operation’s cancellation contract.