Scalable and Maintainable React Project Structure Every Developer Should Use.
Tags: webdev, javascript, react, beginners
Published: 2022-12-28 10:47:25

A good project structure can have a huge impact on how successful a project is in terms of understanding the codebase, flexibility, and maintenance. Projects that are not well structured and maintained can quickly become a big mess and dreadful legacy that no one is too happy to work with.

I will now show you the structure that I very often use in my projects, and explain the reasoning behind it. This structure should be a good starting point for a large-scale application, and you can expand on it depending on the project’s needs. Here is the src structure I can recommend for most projects:

![Image React](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gbd0g28wobkaprband5h.jpg)

Let’s cover the folders from top to bottom.

## __tests__
First, we have the _tests_ folder, which will contain all the test file of  the React application.  I use Jest in most of my CRA application. I see that CRA opted for the use of _filename.test.js_ format when writing tests. But this approach is a bit cumbersome on the eyes and brain. You can write tests in a folder named __tests__ and jest will automatically run the tests in that folder.

## api
The _api_ folder contains the API Layer of our application. It will have methods that are responsible for performing API requests and communicating with a server.

## assets
The assets folder contains _fonts_, _images_, and _videos_. In the fonts, you can keep any custom fonts and typefaces. In images store any pictures used throughout the application.

## components
The _components_ directory contains two directories: _common_ and _specific_. The _common_ directory will contain any reusable components that are commonly used throughout the application. For instance, _buttons_, _form_ components, components related to _typography_, and so on. Any components that are not as common would be placed inside of _specific_ components.

## Hooks
The _hooks_ directory, as the name suggests, would hold any custom and reusable hooks. Note that any hooks that are not really reusable, but are coupled to a specific feature, should be placed in the same directory as that feature. For instance, imagine we have a newsletter form component that contains a form to sign up a user for a newsletter. This component could utilize a hook called _useNewsletterSignup_ that would handle signing up a user. A hook like this shouldn’t be placed in the global _src/hooks_ directory, but rather locally, as it is coupled to the _NewsletterForm_ component. Here’s what it could look like:


![Image hooks](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4it45f65eyqq46bw5v7s.jpg)

## context
The context directory should contain any global-level context state providers.

## layout
_Layout_ directory, as the name suggests, should have components that provide different layouts for your pages. For example, if you are building a dashboard application, you could render different layouts depending on if a user is logged in or not.

## config
In the _config_ directory, you can put any runtime config files for your application and third-party services. For instance, if you use a service like _Firebase_ or _OIDC_ for authentication, you will need to add configuration files and use them in your app. Just make sure not to confuse config with environmental variables, as anything that goes here will be present in the build bundle.

## constants
Here you can put any constant variables that are used throughout the application. It’s a good practice to capitalize your constants to distinguish them from other variables and localized constants in your app.

Below are some examples of defining and using constants:

- Define constants separately

```javascript
// in constants/appConstants.ts
export const APP_NAME = 'Super app'
export const WIDGETS_LABEL = 'Widgets'
```

```javascript
// Somewhere in your app 
import { APP_NAME, WIDGETS_LABEL } from '@/constants/appConstants' 
console.log(APP_NAME) 
```

```javascript
// You can also grab all named exports from the file 
import * as APP_CONSTANTS from '@/constants/appConstants' 
console.log(APP_CONSTANTS.WIDGETS_LABEL) 
```

- Define related constants in one object

```javascript
// in constants/appConstants.ts 
// Create an object with constant values 
export const apiStatus = { 
IDLE: 'IDLE', 
PENDING: 'PENDING', 
SUCCESS: 'SUCCESS', 
ERROR: 'ERROR' 
} 
```

```javascript
// Somewhere in your app
 import { apiStatus } from '@/constants/appConstants' 
console.log(apiStatus.PENDING) 
```

## helpers
Any utilities and small reusable functions should go here — for example, functions to format date, time, etc.

## intl
This directory is optional. Add it if an application requires internalization support. Intl, also known as i18n, is about displaying the content of an app in a format appropriate to the user’s locale. This content can include but not be limited to translated text or specific format of dates, time, and currency. For instance, whilst the UK uses DD/MM/YYYY format, the US uses MM/DD/YYYY.

## services
In larger applications, we might have complex business logic code that is used in a few different places. A code like this is a good candidate to be extracted from components and placed somewhere else, and the _services_ folder is a good candidate for that.

## store
The _store_ folder is responsible for files related to global state management. There are many state management solutions that can be used for React projects, such as _Redux_, _Zustand_, _Jotai_, and many many more.

## styles
You can put global styles, variables, theme styles, and overrides in the _styles_ folder.

## types
Here you can put any global and shareable types. With this approach, you can save time and more easily share the TypeScript code and types you and your team need.

## views
Usually, the views directory only contains route/page components. For example, if we have a page that is supposed to allow users to view products, we would have a component _Products.tsx_ in the views folder, and the corresponding route could be something like this:

```javascript
<Route path=”/projects” element={<Products />} />
```
There is a reason why I said “usually”, though. Many applications have route components in the views, and the rest of the components for it are placed in the components folder. This approach can work for small to medium applications but is much harder to manage and maintain when the number of pages and components grows.

## Summary
Choosing the right folder structure is not an easy task. You need to agree with the team on the structure that suits the application, and what might suit one need, might not suit another. Should hopefully be valid for the next years to come. What would you do differently to ensure a good, maintainable structure? Let me know in the comments below.

**THANK YOU FOR READING** 
I hope you found this little article helpful.  Please share it with your friends and colleagues. Sharing is caring.

Connect with me on [various platforms](https://bio.link/thomassentre)