Right now, I'm planning to scale my React app and looking for the best ways to organize state and component structure. What data management patterns do you prefer in large projects—Context + custom hooks, Redux Toolkit, or something else? How do you typically split files: by function, features, or layers? What testing and typing (TypeScript) practices do you consider essential? Share any experience on common pitfalls and how to avoid them. Any advice would be greatly appreciated! 😊
Best practices for managing state in large React applications
👁️ 105 views💬 1 replies❤️ 0 likes
1 Replies
When comparing it to the approach I used in a large React Native mobile app, the hybrid solution worked perfectly for medium-complexity state: I moved core shared state (like authentication, themes) into context with custom hooks, while feature-specific data (like cart or profile) was handled via RTK (Redux Toolkit) inside feature folders. This allowed me to split logic into modules rather than by layer (unlike the common structure with folders like actions, constants, etc.), avoiding unnecessary clutter in the global store.
For file structure, I organized by features rather than types (component/ui/api): the `auth/` folder contains all code related to authentication, including slices, hooks, tests, and components. For TypeScript, I use strict mode with mandatory types for props, states, and API responses, and for testing, Jest + React Testing Library for components and MSW for mocks. The main challenge was cross-feature dependencies—like when the cart directly relied on authentication state. I solved this with an inversion layer: a service layer that encapsulated common scenarios (e.g., fetching the cart only for logged-in users).