One of the most important aspects of your application is how you organize your project's folders, files, configurations, components, screens, etc...

When you take a project to work on, you start by observing the folder structure and seek to understand how the project is organized, what standards does it use, and how everything across it is related to each other

In this article I will show some of the good approaches you can utilize to build a well organized and scalable frontend architecture

Our 3 main goals:

• Modular: You can plug & play where ever you want to
• Reusability: Move it to another project or break this project into a small one
• Independent: Different components, services & packages can be used in different places

First let us see two good ways to structure your React app project

First Structure:

├── src
│   ├── utils
│   ├── constants
│   ├── redux
│   └── components
│       └── general
│           └── Button
│               ├── button.component.tsx
│               ├── button.props.tsx
│               ├── button.test.tsx
│               └── button.styled.tsx
│   └── screens
│       ├── home
│       └── profile
├── App.tsx
├── package.json
└── README.md

What I usually do, is to call the API inside the screens, and then pass the data to the components, so for example at profile screen, I do getProfile API call, then pass the data to the needed components, which are stored inside components folder

.component holds logic and the JSX code, .styled styled-components, and .props is my typescript interface for that component and .test my unit tests

Styled-components is a library built for React and React Native developers. It allows you to use component-level styles in your applications. Styled-components leverage a mixture of JavaScript and CSS using a technique called CSS-in-JS

Another good pattern that you can follow:

Second Structure

├── src
│   .
│   .
│   └── components
│       └── general
│           └── Button
│               ├── button.container.tsx
│               ├── button.presenter.tsx
│               ├── button.test.tsx
│               └── button.styled.tsx
│

this is a bit different approach which is a good way to write your components in a more organized way

Basically when you add more folders, you will minimize the code inside one file, so more folders and modules you make, smaller, more easy to manage and readable code you will have

My .presenter file is concerned with how things look usually have some DOM markup and styles, and the .container file is responsible with how things work and usually no DOM markup

components

what I like to do inside components is categorize and group all the components inside a folder

├── src
│   .
│   .
│   └── components
│       ├── general
│       ├── inputs
│       ├── buttons
│       ├── labels
│       └── modals
│

inside each folder we will have many other small components, for example under modals I may have ConfirmModal, ResetPasswordModal, EmailNewsletterModal, etc.. this way all my modals will be inside one folder, and we can manage easily our components and access them rapidly

Other folders

• constants every constant that can be used in the project
• redux split your redux state in a separate folder with all the reducers and actions in it (if your new to redux, in simple words; redux is a way that helps you to have global state all over the application, and that state is accessible from any component you want)
• utils inside utils you can nest more folders based on each specific job, (for example you can create a folder "datetime" inside utils which holds several util files, which here are related to time and date logic)
• assets images, icons, etc...
• configs any configuration file (for example AWS, Maps, firebase...)

Tip: I like usually to import my images, icons & svgs inside the constants folder and then export them as constants, which will later help us to import them easily

How you know that you project is structured in a good way?

When you want to create a new component, you should know where to create it based on a well defined pattern. For instance if you want to add new form component inside the profile page, so you know that we have a page named ProfilePage, that imports LoginForm component from components/Forms, and inside the form there are other components like Inputs, Buttons, Labels, all these are generic, so you are able to use the same Form inside another page, and at the same time all the components are reusable as well

Always be consistent and predictable

let us check the two utils folder structure below, and we can do a quick comparison between them

Ex 1 (not good)

├── src
│   └── utils
│       ├── CapitalizeFirstLetter.ts
│       ├── notify.tsx
│       ├── REGEX.js
│       └── roundnumber.js

Ex 2 (very good)

├── src
│   └── utils
│       ├── capitalizeFirstLetter.ts
│       ├── notify.ts
│       ├── regex.ts
│       └── roundNumber.ts

We can obviously see how the minor details effect our project

Always be consistent and know how you name your files like without thinking of it, as if it is an standard of the project

You can always append the purpose of your functions, so for example I'm adding Util or .util, now this is based on your preference but it's always good to do this way. An good example I can give; in vscode you may open several tabs at the same time, and maybe you have two files with the same name, but after this you will be able to differentiate among them

├── src
│   └── utils
│       ├── regexUtil.ts
│       or
│       └── regex.util.ts

Some extra tips

• Use typescript since it will make your work much easier, specially when your dealing with HOC components or when even you are doing regular refactoring
• Check how to implement "clean imports" since it will make all your main parts of the project very easy to be managed and reused

I tried to keep this article high level without writing any code, only dealing with folders/files and showing the right mentality in order to have really good structure

While we are structuring our frontend project it is very important to organize everything and make them scalable, its always good to follow a standard or your own pattern, this way your code will be easier to manage and reuse later