Due to the very nature of ReactJS, there is no defined folder structure, leaving it up to the developer to choose the one that best suits the project to be developed.

However, this often brings quite a few headaches since, in the absence of a standard structure, different ways of approaching this organization often arise, often raising the question of whether we are doing it “well”.

I put the word good in quotes because that concept of “good” is very relative both to the project and to the mentality of the developer or the team in charge of the project. Certain structures are usually optimal for certain mental models but not for others, so my advice is to try different methodologies before choosing yours.

For example, to me the structure proposed by Atomic Design, although it seems very good for small projects, does not fit me mentally in large projects, as it causes certain components under the same logical concept to end up separated in different folders.

So, as long as you do not turn the project into an unmanageable tangle of components, cross dependencies and elements that are located in folders without attending to specific reasons, you can feel calm. At the end of the day it is about enjoying what we do and not being burdened by finding a perfection that in issues like this I do not think exists.

The src folder

For me the src folder is the one that houses all the application code, both in React and React Native projects.

This is also something that we should not worry excessively since the npx create-react-app command itself is responsible for giving it to us.

What is interesting is the folders that I create within this main directory. Let’s see them!

🗂 The components folder

Inside src this we would say that it is the main folder of the application since it will house all the components of our application. I do not separate logical components and presentational components at this level, but I place them all in this folder.

Inside the components folder I have the following subfolders.

common

Where are all those components that I will reuse in different places of the application. This includes, for example, the components to represent form inputs, paint images in different ways, special fields such as dropzones or UI elements such as modal windows or sliders. Let’s say that this folder is the UI Kit of the application and does not have any kind of logic, so it is common to recycle many components that appear here in different projects.

Those components that are made up of a single file appear in the root directly without creating a specific folder for them, while those components that require several parts to function do group them within a folder. In these cases lately I am resorting to an index.js file to be able to shorten imports a little more:

import Dropzone from './Dropzone';export default Dropzone;

So I can later import this component in the following way:

import Dropzone from 'components/common/Dropzone';

without going one step further to reach the component’s .js file:

import Dropzone from 'components/common/Dropzone/Dropzone';

hocs

Although High Order Components are a pattern that is losing steam lately, it is sometimes interesting to use them, especially if we need to recycle layouts throughout the application. Therefore, within the components folder I reserve a folder to house this type of components and thus have them at hand.

layout

Inside the layout folder I have purely presentational components that paint the basic structure of the different views / routes of the application.

For example, if we are developing the typical application with multiple views for anonymous users (registration, login) and the application itself that registered users access, it is likely that these two areas have different structures at the visual level.

Therefore, inside the layout folder is where I place the components in charge of generating this main structure so that the routes it defines use it in order to paint its content.

An example of the type of files I usually locate here is the following:

router

Inside this folder I locate the components that surround those of the React Router library:

And they are responsible for, in addition to painting the component associated with the route, controlling the access logic, preventing users without a session from accessing private areas, for example:

views

Finally, the views of the application are located within the views folder, each one associated with an application path.

Here each view has its own folder, for example Dashboard, and within it I generate subfolders to open the components that make up the final view and that I will not reuse in the application.

For example, the Dashboard view can be made up of different lists of the entities of the application, a series of graphs with statistics and buttons with shortcuts. This would generate the following structure for thesrc/components/views/Dashboard folder:

Dashboard
├── Dashboard.js
├── DashboardView.js
├── index.js
├── Statistics
│   ├── Statistics.js
│   ├── StatisticsView.js
│   └── UserStatistics
│       ├── UserStatistics.js
│       ├── UserStatisticsView.js
│   └── OrderStatistics
│       ├── OrderStatistics.js
│       ├── OrderStatisticsView.js
├── UserList
│   ├── UserList.js
│   ├── UserListView.js

I would like to highlight several things about this structure:

• As you can see, I always have one logical component and another, with the suffix View, which is its presentational component. In this way, logic and view are completely separated, allowing the logic to be reused later to adapt to other platforms.
• Inside are subfolders that house the components that represent the different blocks that make up the list. I do not care excessively that the depth of this tree grows because they are all related and seeing them like this reinforces the sense of hierarchy among them.
• Inside each folder I usually also add components that contains styled-componentes or style sheets.

🗂 The config folder

Inside the config folder I usually add the .js files that add the application settings. For example, the files that define the routes that the application has if we are following the idea proposed in the React Router DOM documentation:

Or files that define certain values such as the URL of the Backend depending on the environment.

🗂 The consts folder

Although sometimes I usually combine the config folder with the const folder, sometimes I separate them according to the number of files they contain.

Within const folder are .js files that define the constants of our application, such as colors, enumerated for certain fields or the codes that represent the different languages supported by the application.

🗂 The contexts folder

In those projects in which I use the Context API, I place here each of the contexts that I define to share the global state between the different components of the application.

The contexts defined here always export two values, the Context itself generated by the React.createContext statement and a ContextProvider that will define context-specific actions, such as a function to modify the value that the context saves.

🗂 The hooks folder

This folder is also self-describing since the hooks of our application will be found in it, for example, useFetch or useUserContext to retrieve certain contexts.

🗂 The images folder

Inside this folder I locate the images of the application, such as logos or SVG graphics.

🗂 The propTypes folder

When I work with objects retrieved from the API and in the absence of using tools like flow or Typescript, what I do is define here custom propTypes in order to represent the shapes of some objects that are received in different components.

For example, the propType representing a user object is as follows:

import PropTypes from 'prop-types';export default PropTypes.shape({name: PropTypes.string.isRequired,surname: PropTypes.string.isRequired,email: PropTypes.string.isRequired,image: PropTypes.string.isRequired});

🗂 The theme folder

The theme folder is responsible for housing the files responsible for generating the global styles of the application, such as colors, fonts, dimensions of the margins or styles of the buttons.

If we are working with a library such as Material UI within this folder, the function responsible for creating the application theme will be in charge as well as all those files that define the styles of our application.

Note. The styledComponents (if we are using this methodology) I put them inside the components/common folder. In the theme folder what I do is define the styles that these components will use later.

🗂 The utils folder

Although sometimes I also call it services when I have been working with Symfony for a long time, here are utilities in the form of a function that I use throughout the application.

Each function is inside its own file (I tend to avoid having files that export various functions in this folder) and encapsulates certain logic in order to reuse it, for example:

export default function generateRandomId() {  return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);}

In summary…

In order for you to have a complete overview of the structure of a project, I leave you a tree generated from one of the projects I have recently worked on:

awesome-app
├── src
│   ├── components
│   │   ├── common
│   │   │   ├── ResponsiveImage.js
│   │   │   ├── Dropzone
│   │   │   │   ├── Dropzone.js
│   │   │   │   ├── Dropzone.js
│   │   │   │   └── ...
│   │   │   └── ...
│   │   ├── hocs
│   │   │   ├── withSidebar.js
│   │   │   └── ...
│   │   ├── layouts
│   │   │   ├── PublicLayout.js
│   │   │   └── ...
│   │   ├── router
│   │   │   ├── PrivateRoute.js
│   │   │   └── ...
│   │   ├── views
│   │   │   ├── Dashboard
│   │   │   │   ├── Dashboard.js
│   │   │   │   ├── DashboardViews.js
│   │   │   │   └── ...
│   │   │   └── ...
│   ├── config
│   │   └── fileSize.js
│   │   ├── router
│   │   │   ├── paths.js
│   │   │   ├── routes.js
│   │   └── ...
│   ├── consts
│   │   └── locales.js
│   │   └── ...
│   ├── contexts
│   │   └── userContext.js
│   │   └── ...
│   ├── hooks
│   │   └── useUserContext.js
│   │   └── ...
│   ├── images
│   │   └── logo.svg
│   │   └── ...
│   ├── propTypes
│   │   └── user.js
│   │   └── ...
│   ├── theme
│   │   └── app-theme.js
│   │   └── ...
│   ├── utils
│   │   ├── blobToFile.js
│   │   ├── generateRandomId.js
│   │   └── ...
│   ├── index.js

Final thoughts

As I mentioned at the beginning, this structure adapts very well to my way of thinking, since all the components follow a hierarchical order, without the need to jump between different levels to go through this structure.

However, one of the problems that may appear is an excessive depth, something that does not worry me much in exchange for maintaining this organization and that is counteracted by a proper naming of the components, which allow them to be located quickly through the Visual Studio Code tools.

Do you want to read more articles like this?

If you liked this article I encourage you to subscribe to the newsletter that I send every Sunday with similar publications to this and more recommended content: 👇👇👇