Managing State Without Losing Your Mind
I spent three years building React applications that were supposed to be simple dashboards. By the end of it, I had enough state management disasters to fill a book. The problems almost never came from React itself. They came from treating every piece of data the same way, which is why having a strategy guide matters more than any single library recommendation. The first thing most people get wrong is where they put their global state. They install Zustand, Jotai, or Redux Toolkit, slap everything into a store, and wonder why their app re-renders like it's on fire. The trick is simpler than you think. Keep component-local state where it belongs, and only lift state up when at least two components need to react to the same change. Everything else is premature abstraction. I once worked on a form-heavy admin panel where every input was controlled through a global store. The form had about 40 fields across six tabs. Each keystroke triggered a store update, and since the store object was recreated on every mutation, every component subscribed to it re-rendered. The page became unusable past 200 characters typed. The fix wasn't better memoization. It was removing the store entirely and using a local state object keyed by field name. Render times dropped from 800ms to 40ms.
When to Reach for a Library vs When to Just Use Context
Context is fine for things like theme toggles, auth state, or locale. It is not fine for data that changes frequently. The common mistake I see repeatedly is someone using createContext for a list of items that gets filtered, sorted, and paginated in real time. That context value updates on every keystroke, and every consumer re-renders. React does not make this expensive by default anymore, but it still adds up across a large component tree. Zustand with the persist middleware will save you from rewriting boilerplate for local storage sync, but it comes with its own gotcha. The persist middleware serializes and deserializes your state on every read and write to storage. For small JSON objects this is invisible. For anything with nested arrays of more than fifty items, you will feel it. I switched a similar pattern to use a custom hook with sessionStorage directly and bypassed the middleware overhead entirely.
Custom Hooks Are Where the Real Strategy Lives
Every time you find yourself repeating the same three lines of state setup, useEffect cleanup, and callback wrapping across components, that is a hook waiting to be extracted. The trick most people miss is that hooks should encapsulate behavior, not just state. A hook called useDebounceValue is useful. A hook called useDebounceValueForSearchInputsThatTriggerApiCalls is also useful and significantly more explicit about what it does. Here is a concrete example. I was building a product search feature that called an API on every input change. The API returned data, I stored it in component state, and I also needed to handle loading and error states. That is seven to eight lines of code repeated across four different pages. I wrapped it into a useSearchQuery hook that accepted an endpoint and a debounce delay, returning data, loading, error, and a reset function. The pages that used it dropped to two lines each. It also meant I could change the debounce timing or error handling strategy in one place instead of hunting through four files.
Get the Full Details
Performance Optimization Without the Paranoia
React.memo, useMemo, and useCallback are tools, not solutions. Using them everywhere creates code that is harder to read and often slower because React still has to compare the values you are memoizing. The rule I follow is straightforward. Wrap a component in React.memo only when it receives props that change infrequently but the component itself renders often as a result of parent updates. Memoize values only when the computation is expensive relative to the render cost. Cache callbacks only when they are passed as dependencies to other memoized hooks or components. I saw a codebase once where every single callback was wrapped in useCallback and every single value in useMemo. The bundle size increased by roughly 12 kilobytes after tree shaking, and page load times went up because of all the extra function allocations happening on every render anyway. Removing half of those memoizations actually improved performance because React spent less time doing shallow comparisons and more time doing actual work.
Server State vs Client State — Stop Confusing Them
This is the biggest category error in React development right now. Data that comes from a server and is displayed, cached, and refetched belongs in a data-fetching library like TanStack Query or SWR. Data that represents the current UI state, like whether a modal is open or what tab is selected, belongs in component state or a lightweight store. Mixing these two categories causes the kind of bugs where a user navigates away, comes back, and their search results are gone because they were stored in local component state instead of being refetched from the cache. TanStack Query handles deduplication, background refetching, and caching automatically. It also gives you pagination and infinite query support out of the box. The one downside is that it adds about 15 kilobytes minified to your bundle. For most projects that is negligible. For a mobile-first app where every kilobyte matters, SWR is lighter and covers the same core use cases without the routing integration that TanStack Query bundles in.
The Testing Strategy Most People Skip
Most teams write unit tests for pure utility functions and integration tests for user flows, but they skip the middle ground. Tests for your custom hooks are where most logic bugs hide before they reach the UI. A hook that manages pagination state might have an off-by-one error that no manual testing catches because you only ever test the happy path. Testing hooks with the React Testing Library's renderHook function takes about five minutes per hook and catches issues like stale closures, missing cleanup in useEffect, and incorrect conditional hook calls. I found a bug this way in a hook that fetched user preferences on mount. The hook was calling the fetch inside a useEffect with no dependency array, which meant it ran on every render instead of just once. The user's preferences would sometimes show stale data because the component would re-render before the fetch completed and overwrite the loading state. This took about ten minutes to reproduce with a test and five more to fix.
Code Splitting That Actually Makes a Difference
React.lazy with Suspense is the standard approach for code splitting. The common mistake is splitting at the route level only. You also need to split heavy components that are not immediately visible, like charts, data tables with complex rendering, or modals that users rarely open. Import those dynamically instead of bundling them with your main bundle. I worked on a reporting dashboard where the initial bundle was around 2.1 megabytes because three charting libraries were imported at the top level. Even though only one chart type was visible on page load, all three were bundled together. Splitting those imports to lazy components reduced the initial bundle to about 800 kilobytes. Page load time on a 3G connection dropped from roughly 6 seconds to 2.5 seconds.
What Doesn't Work Anymore
Class components with lifecycle methods are still maintained in legacy codebases, but starting new projects with them adds unnecessary complexity. The same goes for prop drilling beyond three levels. If your props need to pass through more than two components to reach their destination, a context or store is the right call. Also stop using string refs unless you have a very specific reason. Refs as objects or the callback ref pattern is more predictable and works better with concurrent mode. The one strategy that genuinely fails in production is storing everything in URL search parameters. It works fine for simple filters on a small dataset. It breaks when you have nested filters, pagination, sort order, and column visibility all encoded into a query string that exceeds the browser's URL length limits. I saw this happen on a data analytics tool where the URL grew to 4,000 characters and started failing in Safari. The workaround was switching complex filter state to a server-side session while keeping only the current page number in the URL.
