Cheatsheets are useful for syntax you use rarely enough to forget, and close to useless for the judgment calls that actually separate senior React work from intermediate work - knowing which hook to reach for is trivia; knowing when a pattern is genuinely the right fit for a specific problem is the actual skill. This is less a syntax reference and more the set of judgment calls we actually apply on real projects.
On state management: the question isn’t which tool, it’s where state actually belongs
Before reaching for any state management pattern, the senior-level question is: does this state need to be global at all, or is it genuinely local to one component or a small subtree? A huge share of “state management is complicated” pain we’ve seen in codebases comes from state being lifted higher than it needs to be, not from an inadequate tool. We’ve covered the actual trade-offs between Redux and lighter alternatives elsewhere - but the more foundational skill is correctly scoping state before choosing a tool to manage it.
On useEffect: the honest advice is use it less, not use it better
A meaningful share of useEffect usage we see in codebases we inherit is solving a problem that doesn’t need an effect at all - deriving a value from props or state (which should just be computed directly during render, not synced via an effect) is the most common misuse. The senior-level instinct isn’t “here’s how to write a cleaner useEffect,” it’s “does this genuinely need to be an effect, or is it disguised derived state.” Reaching for an effect should be the last resort after confirming the logic genuinely needs to synchronize with something external to React (a subscription, a manual DOM measurement, a genuinely external system).
On memoization: default to not memoizing, add it deliberately when profiling shows a real problem
useMemo and useCallback sprinkled defensively throughout a codebase, without profiling data showing an actual performance problem, add real complexity and cognitive overhead for a benefit that often doesn’t exist - premature memoization is a genuine anti-pattern, not a best practice. The senior approach: write straightforward code first, profile if there’s an actual, felt performance issue, and add targeted memoization specifically where profiling shows it helps, not as a blanket defensive habit.
On component composition: prefer composition over configuration
A component that grows a long list of boolean props to handle every possible variant is usually a sign it should be composed from smaller, more focused pieces instead - passing children and using composition patterns keeps components simpler and more flexible than an ever-growing prop API trying to anticipate every use case upfront.
On error boundaries: the most under-used tool for production resilience
A huge share of production React apps we inherit have no error boundaries at all, meaning a single component error can take down an entire page rather than being contained to the specific broken piece - this is a genuinely under-adopted, low-effort resilience pattern that deserves more attention than it typically gets in team practice.
What we’d actually recommend
Less time memorizing syntax, more time internalizing the judgment calls above - where state actually belongs, when an effect is genuinely necessary versus disguised derived state, when memoization is solving a real measured problem versus a defensive habit. These are the differences that actually separate maintainable React codebases from fragile ones.
We build with this discipline as standard practice in our React development work. Get in touch if you want a senior-level review of an existing React codebase’s patterns.