Link to this headingContext
When working with React, however, we can run into some problems if we try to use it as-is.
This hook is a "react-friendly" wrapper around setTimeout. You can use it just like you'd use
window.setTimeout, and it'll work as you expect.
Link to this headingUsage
In this example, the first render will happen instantly, with
hasTimeElapsed being false. Then, 5 seconds later, it'll re-render with
hasTimeElapsed set to true.
Any other renders in the meantime, caused by a parent component, won't affect anything.
Link to this headingCancelling
You can cancel the timeout by changing the
delay property to
In this example, if the user clicks the button before the timeout has expired, the timeout will be canceled, and will never fire.
You can also capture the timeout ID to cancel it imperatively:
Link to this headingExplanation
You might be wondering: why is this needed? Can't you just use
There are 3 problems with using
window.setTimeout in React:
- This will break if your application is statically-generated or server-side rendered, since
- A new timeout will be scheduled whenever this component renders, instead of only once when the component mounts. If our parent component re-renders 10 times, we'll schedule 10 timeouts.
- Our callback function is stale; it won't have access to current values for state and props.
Dan Abramov wrote about this discrepancy, and how to overcome it, in a fantastic article about useInterval. The exact same principles apply for
useTimeout. If you're keen to develop a deeper understanding of React, I highly recommend checking it out.