## Things that take time In Level 4 so far, you have seen data fetching, form submission, and navigation. All of these involve **asynchronous operations** -- things that take time and may succeed or fail. This module covers the patterns that handle that uncertainty gracefully. You do not need to implement these patterns. You need to recognize them when reading code and understand what they do for the user experience. ## Loading state patterns You already know the basic loading pattern: show a spinner while data loads. But there are several variations you will encounter in real codebases. ### Spinners The simplest loading indicator. The entire content area is replaced with a spinning icon: ```jsx if (loading) return ; ``` Good for: initial page loads, short waits. Bad for: it destroys the existing layout while loading. ### Skeleton screens Placeholder shapes that mimic the layout of the content: ```jsx function UserCard({ userId }) { const [user, setUser] = useState(null); const [loading, setLoading] = useState(true); useEffect(() => { fetch(`/api/users/${userId}`) .then(res => res.json()) .then(data => { setUser(data); setLoading(false); }); }, [userId]); if (loading) { return (

); } return (

{user.name}

{user.bio}

); } ``` The skeleton has the same shape as the loaded content -- a placeholder rectangle where the avatar will be, grey bars where the text will be. This feels faster because the layout does not jump around when data arrives. When you see `className="skeleton"` or similar in loading states, you are looking at a skeleton screen. ### Inline loading Instead of replacing the whole content, just disable the interactive element: ```jsx ``` This keeps the page intact and only changes the button. Common for form submissions, toggles, and actions that affect one element. ## Error handling patterns ### try/catch in async functions You saw this in Module 4.1. Inside an async function, `try/catch` handles errors: ```jsx async function loadData() { try { const res = await fetch('/api/data'); if (!res.ok) throw new Error(`HTTP ${res.status}`); const data = await res.json(); setData(data); } catch (err) { setError(err.message); } finally { setLoading(false); } } ``` - **try** -- the code that might fail - **catch** -- what to do when it fails - **finally** -- code that runs regardless of success or failure (great for setting `loading` to false) ### Error boundaries Some errors happen during rendering -- a component tries to read a property of `null`, or a child component crashes. Regular try/catch cannot catch rendering errors because they happen inside React's render cycle. React provides **error boundaries** for this: ```jsx function App() { return ( Something went wrong.

}> ); } ``` An error boundary is a component that wraps other components. If anything inside it crashes during rendering, the error boundary catches the error and shows the fallback UI instead of crashing the entire app. When you see `` in code, you know: this is a safety net. If the children crash, the fallback appears instead of a white screen. Error boundaries are often placed: - Around the entire app (so the whole app does not go blank) - Around specific sections (so one broken widget does not take down the page) ### Error states in the UI Different levels of error severity call for different UI treatments: ```jsx // Full-page error if (error) return ; // Inline error banner {error &&

{error}

} // Toast notification useEffect(() => { if (error) showToast({ type: 'error', message: error }); }, [error]); ``` ## Debouncing: waiting for the user to stop When a search input fetches results on every keystroke, it fires a request for "h", then "he", then "hel", then "hell", then "hello" -- five requests when the user only wanted results for "hello". **Debouncing** waits until the user stops typing before making the request: ```jsx function SearchWithDebounce() { const [query, setQuery] = useState(''); const [debouncedQuery, setDebouncedQuery] = useState(''); const [results, setResults] = useState([]); // Debounce: wait 300ms after last keystroke useEffect(() => { const timer = setTimeout(() => { setDebouncedQuery(query); }, 300); return () => clearTimeout(timer); }, [query]); // Fetch only when debounced query changes useEffect(() => { if (!debouncedQuery) return; fetch(`/api/search?q=${debouncedQuery}`) .then(res => res.json()) .then(data => setResults(data)); }, [debouncedQuery]); return (

setQuery(e.target.value)} /> {results.map(r =>

{r.name}

)}

); } ``` The debounce logic: 1. Every time `query` changes, a 300ms timer starts. 2. If `query` changes again before 300ms, the old timer is cleared (the cleanup function) and a new one starts. 3. When 300ms passes without changes, `debouncedQuery` updates. 4. The second useEffect fetches results for the debounced value. This means typing "hello" quickly fires zero requests until the user pauses for 300ms, then fires one request for "hello". You might also see this wrapped in a custom hook: ```jsx const debouncedQuery = useDebounce(query, 300); ``` When you see `useDebounce` or `setTimeout` with `clearTimeout` in a cleanup function, you are looking at debouncing. ## Optimistic updates: updating before the server confirms Remember the "like" button from the prediction prompt? That is an **optimistic update** -- the UI updates immediately, assuming the server will succeed. If the server fails, the update is rolled back. ```jsx function LikeButton({ postId, initialLiked }) { const [liked, setLiked] = useState(initialLiked); async function handleLike() { const previousLiked = liked; setLiked(!liked); // Optimistic: update UI immediately try { await fetch(`/api/posts/${postId}/like`, { method: liked ? 'DELETE' : 'POST', }); } catch (err) { setLiked(previousLiked); // Rollback on failure } } return ( ); } ``` The pattern: 1. Save the current state (`previousLiked`) 2. Update the UI immediately (`setLiked(!liked)`) 3. Send the request to the server 4. If the request fails, revert to the saved state This makes the UI feel instant. The user does not wait for the server. You will see this pattern for: - Like/unlike buttons - Toggle switches - Adding items to a list - Reordering items When you see a state update **before** a fetch call (and a rollback in the catch), you are looking at an optimistic update. ## Retry patterns Sometimes fetches fail due to network hiccups. A retry pattern automatically tries again: ```jsx function DataLoader({ url }) { const [data, setData] = useState(null); const [error, setError] = useState(null); const [retryCount, setRetryCount] = useState(0); useEffect(() => { fetch(url) .then(res => res.json()) .then(data => setData(data)) .catch(err => setError(err.message)); }, [url, retryCount]); if (error) { return (

Failed to load: {error}

); } // ... loading and success states } ``` The trick: `retryCount` is in the dependency array. Clicking "Try Again" increments it, which triggers the useEffect to re-run the fetch. The count itself is not used in the fetch -- it is just a way to force the effect to run again. ## Pattern recognition summary | Pattern | What to look for | What it does | | :-- | :-- | :-- | | Skeleton screen | `className="skeleton"` in loading state | Placeholder shapes while loading | | Debouncing | `setTimeout` + `clearTimeout` in useEffect cleanup, or `useDebounce` | Waits until typing stops before acting | | Optimistic update | State update before fetch, rollback in catch | UI updates instantly, reverts on failure | | Error boundary | `` wrapping components | Catches render errors, shows fallback | | Retry | Button that increments a counter in the dependency array | Lets user retry a failed fetch | | Inline loading | `disabled={isSubmitting}` on buttons | Prevents double-clicks during async ops |

4.4 Common Async Patterns