React folders in general are arranged to improve the quality of a software or product by discovering bugs, issues, and errors. Since there are no defined rules for how to structure and create your code, React is very flexible, which makes it challenging to organize a React project because there are no guidelines.
Rather than going into considerable detail, this article will focus on the general picture when discussing the common folders and files found in React. There is no suitable, universal structure that can be applied outside of the src folder because your files will be highly project-specific and rely on the libraries you use.
Jordan Walke, from Facebook (
now Meta), back in 2011, is a free and open-source framework used for designing user interfaces.
Creating an organized file structure and clean code in React can boost productivity because it makes it easier to understand the code as a whole, which ensures that new features and bug fixes are delivered more quickly.
React has no opinion on how you organize files in folders. However, there are some common strategies in place that you may wish to consider.
The most common folder structure
Given that there is no required or advised file/folder structure for React, the following methods are currently the most widely used to arrange folders:
Grouping by features
Grouping by routers
Grouping by file type;
Grouping by features
Each folder, as its name implies, will include all files that are key to its features, such as JS, CSS, and tests. Every one of its children's attributes will also be present in the parent feature folder.
Pros: Since all features are very simple to visualize for small and medium-sized projects, other developers can easily maintain them.
Cons: You could have duplicate components, which might cause inconsistencies all through the task, and it might not measure well for large projects.
Grouping by routes
Similar to grouping by features, but with the exception that all related routes will be included in the parent folder rather than all children's routes being included in the parent feature.
Pros: With this approach, you can easily structure your views for small and medium-sized projects, making it readily available to other developers, just like with feature grouping.
Cons: Setting up the elements between parents and their children can be incredibly tricky.
Grouping by file type
The file type, in this case, does not refer to the file extension, such as.jsx or.css, as is the case in Angular-based projects. The files will be organized based on the content; for example, all components, such as different pages and API-related files, will be contained within a single folder.
Pros: All elements are global, which makes them more reusable and consistent.
Cons: As the project develops, it is common to have multiple layers of folders, which typically results in a lot of nesting and makes relative imports between folders more difficult.
Pros: works well for teams that are made up of full-stack developers, especially with large and complex projects.
Cons: It is not widely used and can be quite complex for those who are unfamiliar with it.
Popular folders and their usage
The developer is free to name folders however they please. But even so, the following are some of the known folders and what you can anticipate to find in them:
The assets folder usually contains all images, icons, and other assets that are used in the project, such as fonts. Sometimes they can also have the stylesheets for the project if those are not placed in their folder.
Utility services, such as data formatting (which includes date standards and lower/upper case formatting), regex conditions, etc., are typically found in the utils folder.
To hold all API calls together, it is also advisable to have an src/services folder to keep the external API calls separate.
The files that configure the environment and its variables can be found in the config folder.
Which file structure is best for my project?
Every file structure has its benefits and drawbacks, and what this means is that, since every project should have its own needs and specifics, there is no worse or better approach to any project. You should decide which file structure works best for you, your team, and the project, and stick with it (oftentimes, it might be a combination of 2 file structures!).
Taking everything mentioned into account, a folder structure that is organized by file type is the most beneficial because it fits the requirements of vast majority of projects.
*This is not the official Fetchly opinion but the opinion of the writer who is employed by Fetchly*