An options object with defaults
Named options are easy to read and extend. Depending on left and interval (primitives) and reading onDone through useEffectEvent means the inline object and arrow function never restart the timer.
A good hook is named after what it does (useChatRoom, not useMount), takes clear inputs (an options object when there are several), returns stable values and functions so callers' effects don't re-run, and exists only when it actually uses hooks and hides real complexity.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Rewrite useMount(() => { document.title = title; }) as a purpose hook that stays correct when title changes.
This hook returns a new object every render: function useCart() { const [items, setItems] = useState([]); return { items, add: (i) => setItems((x) => [...x, i]) }; }. Make its return value stable.
Turn useFilter(list, "name", true, "asc") into an options-object API and write the hook.
Explain it without notes
Why are hooks like useMount considered an anti-pattern?
What does it mean for a hook to return stable values, and why do callers care?
When should a hook take an options object, and how do you avoid dependency problems with it?
How do you decide whether to write a custom hook at all?
Preview
Console
Nothing logged yet.Expected console output
render: 3
render: 2
render: 1
render: 0
Lift-off!