Folder Structuring Techniques for Beginner to Advanced React Projects

Due to its complete lack of defined notions regarding the structure and writing of your code, React is an incredibly flexible library. However, because React has not established any standards, this flexibility makes it challenging to structure a project using React. We’ll go over three different folder structures in this article that can be applied to projects of all sizes. The complexity of these structures is listed from the simplest to the most complex, but depending on the size of your project, a simpler approach might be preferable.

Introduction

Before talking about the different ways to set up folders, We would like to say one thing. All of these folder structures will only deal with the files and folders inside the src folder. Your files outside of the src folder will depend a lot on your project. Because of this, there isn't a good structure that can be used for all projects, so it will depend a lot on your project and the libraries you use.

First Folder Structure: Simple

In the beginning, when you run the create-react-app, there are no folders in the src folder. Most people create a components folder and a hooks folder as their first two folders. Now, this is a very simple folder structure, it's not a bad way to do things for smaller projects with less than 10-15 components.

Hooks

Every custom hook in your project is stored in the hooks folder. This folder is useful for any size project because almost every project has more than one custom hook, and having a place to put them all can be extremely helpful.

Components

Since every component in your entire application will be contained in the components folder, the simple folder structure, it is very easy to understand. Since this folder can become very difficult to manage as your project grows beyond 10-15 components, our components are dispersed across multiple folders and given more structure in all other folder structures. However, for small projects, a single folder will do just fine without this extra complexity.

tests

This structure's final folder, the tests folder, contains all of your test code. Typically, We can discover that people keep all of their tests in a single folder for smaller projects like this one (that is if they write any tests at all). Overall, We tend to believe this is fine for smaller projects, but as your project gets bigger, the recommendation would be to change this.

Advantages

We can conclude that the most important advantage of this folder structure is its simplicity, but the structure is not that much functional beyond that.

Disadvantages

You'll observe that this folder structure leaves it up to the user to decide what to do with objects like photos, utility functions, React contexts, etc. The reason is that you can get away with merely placing those files in the root of your src folder as smaller projects typically don't have as many of these extra files. Any project larger than a small project should use at least an intermediate folder structure because it will become a mess quickly as your project grows.

Second Folder Structure: Intermediate

As you can see from the image above, this folder structure has a ton more folders that cover just about any file type you could imagine in a React project. With a folder layout like this, you should primarily only have files like your index.js file in the root of your src folder.

The fact that we are now segmenting our project into pages, which contain all the logic for specific pages in a single location, is the other significant difference between this folder structure and the simple folder structure. The ability to find all the data related to your pages in one folder rather than having to search through multiple folders and sift through irrelevant files is really helpful when working on larger projects.

Additionally, you'll see that our tests are now tailored to the particular folder and files they are testing. This makes it simpler to identify the code that has been tested, which in turn makes testing code easier in general when tests are positioned next to the code that is being tested.

Pages

The addition of the pages folder represents the most significant change to this folder structure. Each page of your application should have its own folder in this location. There should be a single root file for your page (usually index.js) and all the files that are specific to that page inside of those page-specific folders. For instance, the Login page in the image above has the root file index.js, the LoginForm component, and a unique hook called useLogin. Since the Login page is the only place that the component and hook are ever used, they are stored with this page rather than in the global hooks or components folders.

The main advantage of this system over the previous (simple) folder structure is the separation of page-specific code from your more general global code. When all of the pertinent code is centralized in a single folder, it is simpler to understand what your application is doing.

Components

Another significant difference in this example is the further subdivision of our components folder into subfolders. These subfolders are quite helpful since they keep your components separated into different groups rather than just being a big blob of them. Our example includes a ui folder that contains all of our user interface elements, such as buttons, modals, cards, etc. For controls related to forms, such as checkboxes, inputs, date pickers, etc., we also have a form folder.

This components folder can be tailored and broken down anyway you see appropriate based on the requirements of your project, but in ideal circumstances, this folder shouldn't grow too large as many of your more intricate components will be kept in the pages folder.

Hooks

The hooks folder is the last folder that somehow repeats the simple folder structure. This folder is nearly comparable to the previous hooks folder, but it only stores global hooks that are used across several pages, not every hook in your application. This is due to the fact that the pages folder houses all page-specific hooks.

Assets

All of the project's photos, CSS files, font files, etc. are located under the assets folder. All that isn't related to coding will be kept in this folder.

Context

All of your React context files used on lots of pages are kept in the context folder. Having a single folder to put them in is particularly helpful when working on larger projects because you will likely utilize several contexts throughout your application. You can swap out this folder with a better collection of folders for storing Redux files if you're using a different global data store, like Redux.

Data

Comparable to the assets folder, the data folder is used to house our data assets, such as JSON files that contain information used in our programs (store items, theme information, etc). Additionally, a file containing global constant variables may be kept in this subdirectory. This is helpful if your program uses a lot of constants, such as environment variables.

Utils

The utils folder is the last new folder that we have in this type of structuring. To store all utility features, including formatters, use this folder. This folder is rather simple, and all of the files inside of it ought to be simple as well. Since a utility function with side effects is probably not just a straightforward utility function, I prefer to only place pure functions in this subdirectory. Of course, there are exceptions to any rule.

Advantages

The fact that each of your files has its own folder is the main advantage of this new approach. There should be almost no files in the root src folder.

Your files are now collocated according to the page they are used in, which is another enormous advantage. This is advantageous since it generally makes understanding, writing, and reading code easier and decreases the amount of global code kept in your general components, hooks, etc. directories. As a project expands, it becomes more and more crucial to have files that are used together stored together.

Disadvantages

The greatest disadvantage of this method is that your pages folder will start to lose value as your application gets bigger and bigger. This is because it is increasingly likely that a single feature will be used across numerous pages rather than simply one when your application obtains more pages. This reduces the use of your pages folder and bloats your other files because you have to relocate the code out of the pages folder and into the other folders in your program.

The pages folder for your to-do page can house all the code for your to-dos, for instance, if your simple to-do list application only keeps track of your tasks on one page. You can no longer retain these to-do files in your pages folder if you later create a second page that allows you to categorize your to-dos under projects. This is because you now have two pages that must display to-do information. Nearly all of your code will be shared over numerous pages until your site reaches a certain size, which is where the sophisticated folder structure comes in.

Third Folder Structure: Advanced

If you look at these two folder structures quickly, you might notice that they have a lot in common, but there is one big difference: the features folder. This features folder is a more elegant way to group code together, and it doesn't have the same problems as the pages folder in the intermediate folder structure, since your features will almost never have a lot of overlap.

Since many of the folders in this structure are the same as those in the intermediate structure, I will only talk about the folders that have changed between these two structures.

Features

The features folder is where these two structures differ significantly. The pages folder from the intermediate structure has an extremely similarly to this folder, except instead of grouping by page, we are grouping by feature. As a developer, this is already simpler to comprehend since, in 90% of cases, when you add new code to a project, you either create a new feature, like adding user accounts, or you modify an existing feature, like adding the ability to edit to-do lists. Because all the code for each feature is in one location, making it simple to update and add to, working with the code is made easier.

This folder's actual organization resembles that of a page in that there are separate folders for each function (authentication, to-dos, projects, etc.), and inside of those folders are all the files related to that feature. The fact that there are different sets of folders within each feature is the major distinction between the pages and features folders. A complete copy of every folder in the src folder (aside from the features folder, obviously) plus an index.js file make up the folder structure for each feature. In your feature, all of your code can be categorized by kind (context, hook, etc.) and still be positioned next to one another, which would be more effective.

Then, everything that may be utilized outside the feature folder for that particular feature is exposed via the index.js file as a public API. With JS, if you make an export in one file, it may be used in any other file you choose. It is typical to want to have a lot of code that is private to the particular feature you are working on. If we just want to expose a few components or methods for our feature in a larger project, this can become an issue. This is where the index.js file comes in. Only the code you wish to be available outside of the feature should be exported in this file, and you should import the code for this feature from the index.js file each time you use it in your application. The advantages of doing this include a substantially reduced global code footprint and easier use of the capabilities due to the constrained API. Even an ESLint rule that forbids any import from a feature folder that doesn't originate from index.js can be used to enforce this.

My recommendation would be to use this import regulation on bigger projects, because it makes use of absolute imports. The following code can be used to configure this using a .jsconfig or .tsconfig file.

Pages

The pages folder is the other significant modification to this new structure. Because all the logic for the features on the pages is in the features folder, this folder now only contains one file per page. In light of the fact that they merely combine a few feature components and some generic components, the files in the pages folder are actually rather straightforward.

Layouts

The layouts folder, which is the first new folder, is really straightforward. Simply said, this is a separate folder where you may put any layout-based components. Examples of this include sidebars, navbars, containers, etc. This folder actually isn't necessary if your application just uses a few distinct layouts; instead, you can just put the layout components in the components folder. However, if your application uses a variety of various layouts, this is a fantastic place to keep them.

Lib

Another straightforward folder is the lib folder. Facades for the various libraries you utilise in your project can be found in this folder. The axios library, for instance, has a file in this folder that allows you to develop your own API on top of the axios API, which you can then use in your application. This means that you would import the file from this folder associated with axios instead of explicitly importing axios into your project.

By doing this, you can consolidate all the library-specific code in your application, making it much simpler to update and replace libraries. It also makes it simpler to adapt third-party libraries to your particular requirements.

Services

The services folder is our final new folder. All of your code for interacting with any external API is located in this folder. On larger projects, you will typically need to access a variety of APIs, and this folder is where you should keep the code that communicates with those APIs. Once more, this simplifies your code because all of the API interaction code is contained in this one folder rather than being dispersed throughout your application.

Advantages

The simplicity of adding/updating code is by far this structure's greatest advantage. It is simple to add new features or update existing features because the majority of the code is divided into various sections. Since files may now be regarded as private, which aids in comprehending the codebase, this separation also simplifies the codebase.

Another advantage is that most business logic is contained inside the features folder, making it relatively easy to understand code outside of it. Again, this makes comprehending and using the code much simpler.

Disadvantages

The complexity of its system is its main drawback. This additional complexity is not a big deal if you are working on a larger-scale application because it ultimately reduces the project's overall complexity, but if you only have a few features or pages, this system may end up being overkill since many of the folders are empty or only contain a few files. As a result, I only advise adopting this folder structure for larger, more complex projects that require the extra division.

Conclusion

Regardless of how big or little your project is, folder organization is essential. With these three folder structure templates, you should be able to modify one of them to meet any size project you have, making it easier for you to create cleaner and better code.