React has changed, your Hooks should too - Matt Smith

"React Hooks have been around for years, but most codebases still use them the same way: a bit of useState, an overworked useEffect, and a lot of patterns that get copy-pasted without much thought. We've all been there. But Hooks were never meant to be a simple rewrite of lifecycle methods. They're a design system for building more expressive, modular architecture. So let's walk through what modern Hook patterns look like today, where React is nudging developers, and the pitfalls the ecosystem keeps running into."

"useEffect is still the most commonly misused hook. It often becomes a dumping ground for logic that doesn't belong there, e.g., data fetching, derived values, even simple state transformations. That's usually when components start feeling "haunted": they re-run at odd times, or more often than they should. useEffect(() => { fetchData(); }, [query]); // Re-runs on every query change, even when the new value is effectively the same Most of this pain comes from mixing derived state and side effects, which React treats very differently."

"React's rule here is surprisingly straightforward: Only use effects for actual side effects, things that touch the outside world. Everything else should be derived during render. const filteredData = useMemo(() => { return data.filter(item => item.includes(query)); }, [data, query]); When you do need an effect, React's useEffectEvent is your friend. It lets you access the latest props/state inside an effect without blowing up your dependency array. const handleSave = useEffectEvent(async () => { await saveToServer(formData); });"

React Hooks often get used as a direct replacement for lifecycle methods, resulting in common patterns: useState, overused useEffect, and copy-pasted logic. Hooks are a design system for building expressive, modular architecture. Concurrent React changes data handling with Server Components, use(), server actions, and framework-driven data loading, plus some async capabilities in Client Components. useEffect frequently becomes a dumping ground for data fetching and derived state, causing components to re-run unpredictably. Effects should be reserved for side effects touching the outside world; derived values belong in render (useMemo or direct computation). useEffectEvent helps access latest props/state inside effects without dependency issues.

Read at Allthingssmitty