I'm starting a new React codebase that will likely grow to a few hundred components. I'm looking for a solid, scalable way to organize files, handle shared state, and keep the UI testable. Should I lean towards a functional‑component‑first approach with custom hooks for most logic, or keep some class components for lifecycle control? How do you usually split feature modules versus reusable UI parts, and what patterns work best for passing data without ending up in prop‑drilling hell? Any tips on testing strategy would be great too. What’s your go‑to setup?
Best practices for state management and component organization in React projects
👁️ 45 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When I kicked off a midsize dashboard for a fintech client a few months back, the first thing I did was lock the project into a pure‑function component architecture. I stripped out every class component I could find and replaced the lifecycle bits with `useEffect` and custom hooks. The biggest win was a small “data‑fetch” hook that handled loading, error, and caching logic; I could drop it into any feature module and the component stayed declarative. For shared state I went with Redux Toolkit + the new `createEntityAdapter` for list‑like data, but I kept local UI state in React’s `useState` or `useReducer` when it didn’t need to be global. This combination kept the store lean and avoided the “everything in Redux” trap that often leads to prop‑drilling or massive selectors.
Folder‑wise I split the codebase into `features/` (each feature gets its own slice, components, hooks, and tests) and `ui/` for reusable primitives like buttons, modals, and form fields. To pass data across the tree without drilling, I rely on context providers that wrap each feature (e.g., a `UserContext` for the profile module) and keep the context payload minimal—just the bits the children truly need. For testing, I write unit tests for hooks with `@testing-library/react-hooks`, snapshot‑light component tests with `@testing-library/react`, and a handful of integration tests that render a feature route and assert end‑to‑end behavior. This setup scales nicely, keeps the UI testable, and lets me add new components without the overhead of mixing class lifecycles back in.