Last week I was cleaning out an old repo and found a file called HOOKS_RULES.md that I wrote for a client team in 2023. Fourteen rules. I read it over coffee and winced, because more than half of it is now wrong or pointless. Wrap every callback in useCallback. Memoize before you profile. Fetch in useEffect with a cleanup flag. All of it written with total confidence by a slightly younger me.<\/p>\n
React 19 and the React Compiler deleted a whole genre of hooks advice, including some I was still handing out last year. So this post is the 2026 rewrite of that file: what I dropped, what I kept, and the code that changed. If your code review comments still enforce the 2023 rules, some of them are actively making your codebase worse. Mine were.<\/p>\n
Three casualties stand out when I reread that file.<\/p>\n
The first was “memoize aggressively.” I had a rule that any function passed as a prop gets useCallback, no exceptions. The second was “fetch in useEffect,” complete with the ignore-flag dance to avoid race conditions. The third was “extract a custom hook once a component passes 100 lines,” which produced hooks like useProfilePageLogic that were impossible to test and were reused exactly nowhere.<\/p>\n
None of these were stupid at the time. They were workarounds for real problems. The interesting part is that all three problems got solved upstream, and the workarounds are now dead weight.<\/p>\n
This is the big one. The React Compiler<\/a> hit stable in 2025, and it memoizes components and hooks automatically at build time. Here’s what a search component looked like under my 2023 rules:<\/p>\n And here’s the same component today, with the compiler enabled:<\/p>\n The second version isn’t lazier. It’s better. The compiler applies memoization more consistently than I ever did, and it can’t forget a dependency. I wrote up the full migration, including the two components where the compiler bailed out and I kept manual memoization, in what happened when I stopped memoizing<\/a>.<\/p>\n One caveat I learned the slow way: the compiler only optimizes code that follows the Rules of React. If your component mutates props or reads refs during render, the compiler skips it silently and you get the old performance. Keep eslint-plugin-react-hooks on error, not warn. The lint rules are how you find out the compiler gave up on you.<\/p>\n My 2023 file had a whole section on fetching in effects, with this pattern copied into probably a dozen client projects:<\/p>\n Every line of that is boilerplate protecting against a race condition that the platform now handles. With React 19’s The honest caveat: Effects still have a job. That job is synchronizing with systems outside React: a WebSocket, a map library, an analytics call. If the effect only moves React state around, it probably shouldn’t exist.<\/p>\n The 2023 rule extracted hooks by line count. The 2026 rule extracts hooks by question: would I want this exact logic in a second component? If yes, extract. If I’m just hiding length, I leave it inline, or split the component instead.<\/p>\n\/\/ React 18, the old way\nfunction SearchResults({ query, onSelect }) {\n const results = useMemo(() => filterResults(query), [query]);\n const handleSelect = useCallback(\n (id) => onSelect(id),\n [onSelect]\n );\n return <ResultList results={results} onSelect={handleSelect} \/>;\n}\n<\/code><\/pre>\n\/\/ React 19 + compiler\nfunction SearchResults({ query, onSelect }) {\n const results = filterResults(query);\n const handleSelect = (id) => onSelect(id);\n return <ResultList results={results} onSelect={handleSelect} \/>;\n}\n<\/code><\/pre>\nuseEffect is not a data-fetching hook<\/h2>\n
\/\/ The 2023 ritual\nfunction Profile({ userId }) {\n const [user, setUser] = useState(null);\n\n useEffect(() => {\n let ignore = false;\n fetchUser(userId).then((data) => {\n if (!ignore) setUser(data);\n });\n return () => {\n ignore = true;\n };\n }, [userId]);\n\n if (!user) return <Spinner \/>;\n return <h1>{user.name}<\/h1>;\n}\n<\/code><\/pre>\nuse<\/code> and a Suspense boundary, the component becomes:<\/p>\n\/\/ React 19\nfunction Profile({ userId }) {\n const user = use(getUser(userId));\n return <h1>{user.name}<\/h1>;\n}\n<\/code><\/pre>\ngetUser<\/code> needs to return a cached promise, because creating a fresh promise on every render will loop. In practice I let React Query or a framework loader own that cache and read it with use<\/code>. The React docs are direct about this in You Might Not Need an Effect<\/a>, which I’d call required reading, except I ignored it for a year, so I’ll just say it’s the page I wish I’d read sooner. I covered where the loading states went in the loading states I stopped writing<\/a>.<\/p>\nA custom hook has to earn its name<\/h2>\n