Scalable Folder Architecture
In this page:
Simple Structure for Small Apps
For a small app, a flat structure — one components/ folder, one hooks/ folder, maybe a utils/ folder — is often perfectly sufficient and easy to navigate.
Adding more elaborate structure before it's actually needed can add friction without real benefit.
- Start simple.
- You can always reorganize into a more elaborate structure later once the app's real shape becomes clear.
Example: Creating a Flat Folder Structure
$ mkdir -p src/components src/hooks src/utils
$ ls src
components hooks utils App.jsx main.jsx
⚠️ Run this in your own terminal or Node.js environment.
Feature-Based Structure for Larger Apps
As an app grows, grouping files by FEATURE (all of a shopping cart's components, hooks, and logic together in one features/cart/ folder) rather than by file TYPE keeps related code physically close together, making it easier to find everything relevant to one feature at once.
Example: Creating a Feature-Based Folder Structure
$ mkdir -p src/features/cart/components src/features/cart/hooks
$ ls -R src/features/cart
src/features/cart:
components hooks cartSlice.js CartPage.jsx
src/features/cart/components:
CartItem.jsx CartSummary.jsx
⚠️ Run this in your own terminal or Node.js environment.
Consistency Over Perfection
There's no single universally correct folder structure — different teams and frameworks favor different conventions successfully. What matters most is picking ONE approach and applying it consistently, so anyone on the team (or future you) can predict where to find or add a given file.
- Organizing purely by file TYPE (one giant components folder, one giant hooks folder) instead of by FEATURE, making related files scattered far apart.
- Over-engineering folder structure for a tiny app that doesn't need it yet.
- Not having any consistent convention at all, letting each contributor organize files differently.
- Small apps can stay simple: a flat components/ folder is often enough.
- Larger apps often benefit from feature-based folders (features/cart/, features/auth/) grouping related components, hooks, and logic together.
- Consistency matters more than any one correct structure — pick a convention and apply it uniformly.
- Folder structure should evolve with the app; premature over-organization can add friction early on.
No React-version restriction — this is a project organization convention, not an API.
Chapter Quiz — Complete all 14 topics to unlock
0/14 topics done
Complete these topics first:
- Error Boundaries
- React Portals
- Modals using Portals (practical use)
- React Suspense
- Code Splitting with React.lazy
- Introduction to Server Components
- Introduction to Next.js (server-side React)
- Using React with TypeScript
- Scalable Folder Architecture
- Common React Design Patterns
- Component Documentation with Storybook
- Accessibility (a11y) in React
- i18n with react-i18next
- React Security Best Practices