| Name |
Description |
src/ |
All frontend source code lives here. |
public/ |
Static files served as-is (e.g., index.html, favicon). |
components/ |
Reusable UI elements, typically presentational. |
pages/ |
Route-specific views that may compose multiple components. |
hooks/ |
Custom React hooks, often encapsulating logic. |
styles/ |
Global styles like resets, variables, or utility classes. |
assets/ |
Images, fonts, icons used in the app (excluding public). |
services/ |
API calls or business logic related to server communication. |
store/ or context/
|
Centralized state management setup (Redux, Zustand, Context API). |
tests/ or __tests__/
|
Optional central place for test utilities. |
| Name |
Description |
| Feature folders |
Co-locate logic, components, styles, and tests per feature (/features/auth/). |
| Dumb vs Smart components |
Keep presentational and logic-heavy components separate. |
| Domain-driven boundaries |
Organize files based on business areas (e.g., /dashboard/, /profile/). |
| Export surfaces |
Use index.js files to define what is exposed from folders. |
| Name |
Description |
| One folder per component |
Group .jsx, .module.css, .test.js under a folder like Button/. |
| PascalCase naming |
Use PascalCase for all component and folder names. |
| Dumb components |
Stateless, reusable, UI-focused, ideally in components/. |
| Container components |
Stateful, logic-handling components, often located in pages/ or containers/. |
| Co-location |
Place styles and tests next to the component file itself. |
| Name |
Description |
| Global styles |
Include resets and variables in styles/ or App.css. |
| Scoped styles |
Use CSS Modules (.module.css) or CSS-in-JS to limit scope. |
| BEM naming |
Follow BEM for class names when using plain CSS. |
| Utility-first |
Adopt frameworks like Tailwind with configuration stored in tailwind.config.js. |
| Theming |
Centralize color and spacing tokens in a single config file or CSS variables. |
| Name |
Description |
| Route-to-page mirroring |
Match folder structure in pages/ to routes (e.g., pages/blog/Post.jsx → /blog/post). |
| Central route map |
Store all route constants in a single file (e.g., routes.js). |
| Nested folders for nested routes |
Use pages/dashboard/settings/ to represent subroutes. |
| Lazy-loaded routes |
Dynamically import heavy pages or feature areas. |
| Name |
Description |
services/ |
One folder per domain, like authService.js, userService.js. |
| Centralized API client |
Wrap fetch/axios in a client.js with interceptors and error handling. |
| Data shaping |
Transform API responses in services, not in components. |
| Endpoint constants |
Define all endpoint paths in a constants/endpoints.js file. |
| Name |
Description |
| DAO / DTO pattern |
Use DTOs (Data Transfer Objects) to define the expected structure of data received from or sent to the backend. Use DAOs (Data Access Objects) to abstract API communication. This creates a clean separation between data shape and transport logic. Example: user.dto.js defines UserDTO, and user.dao.js uses fetchUser(): Promise<UserDTO>. This improves validation, IDE support, and portability. |
entities/ |
Top-level folder organizing domain models (e.g., user/, product/, order/). Each folder contains domain-specific logic and transport layers. |
user/user.dto.js |
Defines shape of data for this domain (e.g., UserDTO, CreateUserDTO). Used for typing, validation, and transformation. |
user/user.dao.js |
Contains API methods like getUserById(id) or createUser(dto). Imports DTOs and uses the central API client. |
user/user.mapper.js (optional)
|
Converts raw API response to UserDTO or from form values to DTO for sending. Helps when backend structure differs from frontend needs. |
user/index.js |
Entry point for the user/ entity; re-exports dao, dto, and optionally selectors or utilities. |
| Use case |
Promotes isolation and strong typing per domain. Encourages clean domain boundaries and better long-term maintainability. |
| Name |
Description |
| Centralized folder |
Group logic in store/ (Redux) or context/ (Context API). |
| Co-located feature slices |
Place slices (reducers/actions) per domain in separate folders. |
| Custom hooks |
Abstract state logic into hooks (e.g., useAuth.js, useTheme.js). |
| Avoid prop drilling |
Use context or state libraries to share data across deeply nested trees. |
| Name |
Description |
| Co-located tests |
Keep *.test.js next to components they test. |
| Shared test helpers |
Reuse common mocks and renderers from tests/helpers/. |
| Snapshots |
Store snapshots in __snapshots__/ or next to tests. |
| E2E location |
Place Cypress or Playwright tests in e2e/ or tests/e2e/. |
| Name |
Description |
| Components |
PascalCase, e.g., UserProfile.jsx. |
| Hooks |
camelCase prefixed with use, e.g., useUserData.js. |
| CSS Modules |
ComponentName.module.css. |
| BEM classes |
.card__title, .card--active for clarity. |
| Constants |
UPPER_SNAKE_CASE for global strings, keys, routes. |
Let me know if you'd like this output as markdown, JSON, or split into separate files.