Consider a Next.js error boundary component that uses a reset function to clear the error state. What is the expected behavior after calling reset?
import { useState } from 'react'; function ErrorBoundary({ children }) { const [hasError, setHasError] = useState(false); function reset() { setHasError(false); } if (hasError) { return <button onClick={reset}>Try again</button>; } return children; }
Think about what resetting error state means for rendering.
Calling reset clears the error state, so the component re-renders its children normally without error.
Which option correctly fixes the syntax error in this reset handler?
function reset() { setHasError = false; }
Remember how to call a state setter function in React.
State setters are functions and must be called with parentheses and the new value.
Given this error boundary code, why does clicking the reset button not clear the error?
function ErrorBoundary({ children }) { const [hasError, setHasError] = useState(false); function reset() { hasError = false; } if (hasError) { return <button onClick={reset}>Try again</button>; } return children; }
Think about how React state updates work.
Directly assigning to the state variable does not trigger a re-render. The setter function must be used.
In this error boundary, what is the value of hasError after calling reset() two times in a row?
const [hasError, setHasError] = useState(true); function reset() { setHasError(false); } reset(); reset();
Consider how React batches state updates.
Calling setHasError(false) twice keeps the state false after both calls.
Which reason best explains why implementing a reset function in Next.js error boundaries improves user experience?
Think about what users want when an error happens.
Resetting error state lets users try again without a full page reload, improving experience.