How do you cancel in-flight API requests when a component unmounts in CSR?
Cancel in-flight API requests in CSR components using AbortController with fetch, cleaning up in useEffect, or using data fetching libraries like SWR or React Query that handle cancellation automatically
In Client-Side Rendering (CSR), when a component unmounts while an API request is still in flight, React will throw an error if you try to update the state of an unmounted component. More importantly, the request continues to consume resources and may later attempt to update state that no longer exists, causing memory leaks and console warnings. The solution is to cancel in-flight requests during cleanup. The modern approach uses the AbortController API with fetch, which actually cancels the underlying network request, preventing it from ever resolving and calling setState on an unmounted component.
Modern data fetching libraries like SWR and React Query handle cancellation automatically, along with caching, deduplication, and many other edge cases. They're the recommended approach for production applications as they eliminate entire classes of bugs and provide better performance out of the box.
- 1
AbortController is supported in all modern browsers (Chrome, Firefox, Safari, Edge) .
- 2
For older browsers, you can use a polyfill or fall back to the isMounted flag pattern .
- 3
The isMounted flag alone prevents state updates but doesn't stop the network request from completing .
- 4
For production apps, the combination of AbortController + isMounted provides the most robust solution when not using a library .
Scenario Questions
- 1
Imagine you have a functional component that fetches user data with fetch inside useEffect. How would you make sure the request is cancelled if the component unmounts before the response arrives?
- 2
What would happen if you didn't clean up the fetch request when the component unmounts, and the response tries to update state?
- 1
You notice a warning about a memory leak after navigating away from a page that uses Axios to load a list. Walk me through how you would fix it and why the previous implementation failed.
- 2
Suppose a component can trigger two different API calls based on user interaction, and the user can quickly switch tabs causing the component to unmount. How would you coordinate cancellation of both in‑flight requests?
- 3
Why might you choose AbortController over a simple isMounted flag, and what trade‑offs does each approach have in a Next.js CSR page?
- 1
Design a reusable data‑fetching hook for a Next.js app that automatically cancels in‑flight requests on unmount, works with both client‑side navigation and SSR hydration, and avoids race conditions. What APIs would you use and why?
- 2
In a large page with dozens of child components each making their own fetch, how would you prevent a cascade of cancellations from hurting performance, and what patterns would you apply?
- 3
If you were using React Query or SWR in a Next.js project, how does their built‑in cancellation interact with component unmount, and what would you need to configure to ensure no stale updates?
- 1
Across multiple teams building a shared Next.js monorepo, how would you enforce a consistent strategy for cancelling in‑flight requests, and what tooling or conventions would you introduce?
- 2
When migrating legacy class components that used componentWillUnmount to cancel XHRs to modern functional components with the app router, what architectural considerations and pitfalls would you watch for?
- 3
If you need to support edge‑runtime API routes that stream data to the client, how would you propagate cancellation signals from the client component back to the edge function to stop unnecessary processing?
Follow-up Questions
- ❓How would you test that your cancellation logic works correctly?
- ❓What edge cases could still cause a stale update even with abort?
- ❓Can you compare the impact on bundle size of using AbortController versus a third‑party library for cancellation?