# React Interview Prep: Don't Get Stung by Stale Search Results You’re deep in React interview prep, grinding [LeetCode](/en/compare/preplyer-vs-leetcode), explaining `useEffect` dependency arrays for the hundredth time. Then, the interviewer drops a scenario on you: "Imagine a search results page. A user types 'Redux', hits enter. Results load. They quickly change their mind, type 'Zustand', hit enter again. But wait, for a split second, they see 'Redux' results flash before 'Zustand' appears. What's happening? How do you fix it?" This isn’t a trick question; it's a common, real-world bug that trips up plenty of folks. It's about stale search results, and it's a fantastic way to see if you actually understand asynchronous React, or if you just memorized the lifecycle methods. ## The Async Dance: Why Results Get Stale Let's break down that "Redux" then "Zustand" flash. When the user types "Redux" and submits, your component probably kicks off an API call. That call goes out, takes some time, maybe 200ms, maybe 500ms depending on network conditions and server load. While that first request is in flight, the user types "Zustand" and submits again. A *second* API call goes out. Now you have two requests outstanding. Which one finishes first? You don't know. The network is a wild place. Maybe the "Zustand" request, being slightly later, hits a faster server or a less congested route and returns first. Or maybe the "Redux" request, already halfway there, finishes up, updates your component state, and *then* the "Zustand" request finishes, overwriting the "Redux" results. The flash happens when the *earlier* request returns *after* a later request has already started, or even finished, but *before* the later request's data is fully rendered. Your component updates with data that's no longer relevant to the user's *current* intent. It's a classic race condition. ## Solutions: The Contenders So, how do we prevent this embarrassing flicker? There are a few well-trodden paths, each with its own pros and cons. You'll want to be able to discuss these trade-offs. ### 1. The Cleanup Function (`useEffect`'s Secret Weapon) This is probably the most common and often the cleanest solution in React components. If you're using `useEffect` for data fetching, you know it can return a cleanup function. Most people think of this for unsubscribing from event listeners or clearing timers. But it's perfect for aborting network requests. When your `useEffect` re-runs (because the search query changed), its cleanup function from the *previous* render runs *before* the new effect callback. If you can, you tell the pending API request, "Hey, never mind, I don't need you anymore." How do you tell an API request to "never mind"? The `AbortController` API is your friend here. You create an `AbortController` instance, pass its `signal` to your `fetch` call's options, and then in your cleanup function, you call `controller.abort()`. ```javascript import React, { useState, useEffect } from 'react'; function SearchResults({ query }) { const [results, setResults] = useState([]); const [loading, setLoading] = useState(false); const [error, setError] = useState(null); useEffect(() => { if (!query) { setResults([]); return; } setLoading(true); setError(null); const abortController = new AbortController(); const signal = abortController.signal; async function fetchResults() { try { const response = await fetch(`/api/search?q=${query}`, { signal }); if (!response.ok) { throw new Error('Network response was not ok'); } const data = await response.json(); setResults(data); } catch (err) { if (err.name === 'AbortError') { console.log('Fetch aborted:', query); // Don't set error if it was explicitly aborted by us } else { setError(err.message); } } finally { setLoading(false); } } fetchResults(); return () => { // This cleanup runs when 'query' changes or component unmounts abortController.abort(); // Abort the ongoing fetch request }; }, [query]); if (loading) return

; if (error) return

Error: {error}

; if (results.length === 0 && query) return

No results for "{query}"

; if (results.length === 0 && !query) return

Start typing to search!

; return (

{item.name}

); } ``` This is robust. It explicitly cancels the outgoing request, preventing its data from ever reaching your `setResults` call. ### 2. The Request ID / Token Approach Sometimes, you can't cancel a request. Maybe you're using a third-party library that doesn't expose an `AbortController`-like mechanism, or you're dealing with WebSockets. In these cases, you need a way to track which request is "the current one." You can assign a unique ID to each request you initiate. When the request completes, you check if its ID matches the "latest" request ID. If it doesn't, you discard the results. ```javascript import React, { useState, useEffect, useRef } from 'react'; function SearchResultsWithToken({ query }) { const [results, setResults] = useState([]); const [loading, setLoading] = useState(false); const [error, setError] = useState(null); const latestRequestId = useRef(0); // Use a ref to persist across renders useEffect(() => { if (!query) { setResults([]); return; } setLoading(true); setError(null); const currentRequestId = ++latestRequestId.current; // Increment and assign async function fetchResults() { try { const response = await fetch(`/api/search?q=${query}`); if (!response.ok) { throw new Error('Network response was not ok'); } const data = await response.json(); // Only update state if this is still the latest request if (currentRequestId === latestRequestId.current) { setResults(data); } else { console.log('Discarding stale results for:', query, ' (request ID:', currentRequestId, ')'); } } catch (err) { if (currentRequestId === latestRequestId.current) { // Only set error for the current request setError(err.message); } } finally { if (currentRequestId === latestRequestId.current) { // Only set loading for the current request setLoading(false); } } } fetchResults(); // No cleanup function needed here for request cancellation, // as we're handling staleness by checking the ID post-fetch. }, [query]); if (loading) return

; if (error) return

Error: {error}

; if (results.length === 0 && query) return

No results for "{query}"

; if (results.length === 0 && !query) return

Start typing to search!

; return (

{item.name}

); } ``` This works well when you can't cancel. The downside: the request still completes, consuming bandwidth and server resources. For very high-frequency interactions, that might matter. ### 3. Debouncing or Throttling Inputs This isn't a direct solution to stale *results*, but it's a preventative measure that reduces the *likelihood* of stale results by limiting how often you even *make* requests. * **Debouncing**: You wait for a period of inactivity before firing the API call. For a search box, this means the API call only happens after the user stops typing for, say, 300ms. If they type "Redux", then "Zustand" quickly, only the "Zustand" request might ever get sent. * **Throttling**: You ensure the API call fires at most once every X milliseconds. If they type quickly, requests are spaced out. Libraries like Lodash provide `debounce` and `throttle` utilities. You can integrate them with `useState` and `useEffect`. ```javascript import React, { useState, useEffect, useMemo } from 'react'; import { debounce } from 'lodash'; // npm install lodash function DebouncedSearchResults() { const [searchTerm, setSearchTerm] = useState(''); const [results, setResults] = useState([]); const [loading, setLoading] = useState(false); const [error, setError] = useState(null); // This effect fetches results based on `searchTerm` useEffect(() => { if (!searchTerm) { setResults([]); return; } setLoading(true); setError(null); const abortController = new AbortController(); const signal = abortController.signal; async function fetchResults() { try { const response = await fetch(`/api/search?q=${searchTerm}`, { signal }); if (!response.ok) { throw new Error('Network response was not ok'); } const data = await response.json(); setResults(data); } catch (err) { if (err.name === 'AbortError') { console.log('Fetch aborted for debounced search:', searchTerm); } else { setError(err.message); } } finally { setLoading(false); } } fetchResults(); return () => { abortController.abort(); }; }, [searchTerm]); // `searchTerm` is the debounced value // This handles the user input and debounces the `setSearchTerm` call const debouncedSetSearchTerm = useMemo( () => debounce((value) => setSearchTerm(value), 300), [] ); const handleChange = (e) => { debouncedSetSearchTerm(e.target.value); }; return (

{loading &&

} {error &&

Error: {error}

} {results.length === 0 && searchTerm && !loading &&

No results for "{searchTerm}"

} {results.length === 0 && !searchTerm && !loading &&

Start typing to search!

}

{item.name}

); } ``` Debouncing is a huge win for user experience and server load. It works best *in conjunction* with request cancellation, not as a replacement. You debounce to reduce the number of requests, and you cancel the ones that still manage to overlap. ## The Interviewer's Follow-Up: "What About Caching?" Good interviewers won't stop there. They'll ask about caching. If a user searches "Redux", then "Zustand", then "Redux" again, should you hit the API for "Redux" a second time? Probably not, if the data hasn't changed. Libraries like React Query (TanStack Query) or SWR shine here. They handle not just caching, but also: * **Deduplication**: If two components try to fetch the same data, they'll often share a single request. * **Stale-while-revalidate**: They can show stale data immediately while fetching fresh data in the background. * **Automatic refetching**: On window focus, on reconnect, or after mutations. * **Request cancellation**: Many of them handle this under the hood for you. Using a dedicated data fetching library dramatically simplifies your component code and often gives you better performance and user experience out of the box. If you're building anything non-trivial, you should seriously consider one. ## The Honest Truth: It Depends Look, there's no single "right" answer that always applies. For a simple internal tool with low traffic, a basic `useEffect` with `AbortController` might be perfectly fine. For a high-traffic e-commerce search with complex filters, you're almost certainly going to reach for React Query and debounce the input. Your choice depends on: * **Complexity of data fetching**: Is it just one endpoint, or many interdependent ones? * **Performance requirements**: How critical is it to show results immediately versus conserving bandwidth? * **User expectations**: How fast do users expect results, and how forgiving are they of a flicker? * **Team familiarity**: What tools does your team already know and support? Don't introduce a new library just because it's "cooler" if your team will struggle to maintain it. During an interview, articulate these trade-offs. Show you understand the problem space, not just one isolated solution. Explain *why* you'd choose one approach over another in a given scenario. That's what senior engineers do. ## Ready to Ace Your Next Interview? Practice with AI-powered [mock interview](/en/interview-prep)s tailored to your target role and company. [Start Practicing for Free](/sign-up) | [Explore Interview Prep](/en/interview-prep)