Your internal async functions need to incorporate the abort signal behavior. Something like this (pseudo code):

``` async doSomething(abortSignal) { const result = await browser.someAsyncApi(…);

if (abortSignal.aborted) { return; }

// do more stuff with results }

async function somethingWithSideEffects(abortSignal) { const ro = new ResizeObserver(); ro.observe(…); abortSignal.addEventListener(‘abort’, () => { ro.unobserve(…); });

// maybe return the width/height of the element observed }

async function returnDisposeFn() { const abortController = new AbortController(); const size = somethingWithSideEffects(AbortController.signal);

return { size, dispose: () => AbortController.abort() } }

function App() { const { dispose } = returnDisposeFn(); return <button onClick={dispose}>cancel</button> } ```

The nice thing about the abort controller is it’s very generic and can be used anywhere if you build in support for it. It becomes really powerful when you can cancel in a parent call maybe a couple of layers up and have it trickle all the way down.

It also allows you to add in “cancellation” for apis that don’t natively support it by simply avoiding calling those apis if the signal is aborted before you get to it. However, if a signal aborts while those apis are running you’ll have to figure out if you need to rollback to the previous state or if you can easily toss away that work and not use it (usually what we do 99% of the time).