React
A component model with no opinions on state, data, or structure — every architectural decision lands in your lap.
React's flexibility is a genuine design constraint: the absence of built-in opinions on state management, data fetching, and component responsibility pushes every architectural decision to the application layer. That means the structural quality of a React codebase is entirely a function of the decisions made at the start.
My baseline rule for component boundaries is that a component owns its UI and nothing else. Data fetching lives in TanStack Query — not in components, not in context, not in useEffect. That separation is the single decision that keeps React codebases from accumulating async state debt. Server state (anything that lives on a remote) goes through TanStack Query with explicit stale times and invalidation logic. Client state (UI toggles, form draft values, modal open/close) stays local and minimal, almost always useState or useReducer directly in the component that owns it. I almost never reach for a global client state library because that boundary holds most of the complexity. For performance, my starting point is the React DevTools Profiler's commit phase view — I look at what rendered in each commit, why it rendered (prop change, state change, context change), and whether it needed to. Unnecessary re-renders usually trace back to unstable references: inline object/array literals in JSX, callbacks recreated on every render, or context values that change shape on every provider render. I apply memo and useCallback at those specific callsites, not as a blanket pattern. Key prop hygiene matters for list stability. What I don't do is memo everything speculatively — that creates its own maintenance surface.
Architecture Review
I map the server/client state boundary across the codebase — what's remote state being stored locally, what components are doing work that belongs in a query layer, and what the TanStack Query cache topology actually looks like versus what it should. The output is a concrete list of boundary violations and what it takes to fix them.
State Management Modernization
The Redux or Context → TanStack Query migration pattern is well-defined: remote data moves into queries with proper cache keys and invalidation, reducers managing fetched state get deleted, and components shed the useEffect chains that were keeping local state in sync with the server. What remains is leaner and the data flow is traceable.
Performance Optimization
I start with the React DevTools Profiler's commit timeline — every render has a reason (prop change, state change, context update) and the question is whether that reason is real. Most unnecessary re-renders come from unstable references created at render time: inline objects, recreated callbacks, context values that change shape. I trace those back to their source and apply memo or useCallback at the specific callsite, not broadly.
SaaS Web Applications
Multi-route applications where auth state, user data, and feature-specific remote state each need their own cache scope. TanStack Query's per-query stale time and invalidation model fits this well — different data has different freshness requirements and that's expressible at the query level.
Design System Development
Component libraries where the contract between a component and its consumer is entirely in props and composition — no internal data fetching, no context assumptions. That constraint is what makes components portable across product surfaces.
Dashboard & Analytics UIs
Data-heavy interfaces where multiple queries feed a single view. The challenge is coordinating loading states, error boundaries, and refetch behavior across independent queries without turning the parent component into an orchestration layer. TanStack Query's parallel and dependent query patterns handle this without manual coordination logic.
Let's talk React.
No pitch. Just a technical conversation about the problem you're working on.