CODING ADVICE

How to create the Best React File Structure

Guidelines to optimize your project hierarchy

React is a very flexible component library and there’s no specific way to layout files. Having your own flavor of project structure is fine for small projects, but its real issues come out when managing large projects. Even though complete freedom is good it should be reined in. To find your own best react file structure is a journey of several trials and errors thus it is better to put down some ground rules before going out on your React journey 😉.

Over the past few months, I worked on quite a few React projects from corporate to personal. From the almost depreciated Class components to the hooks and functional components that are currently in vogue, I have used all. In all these projects my custom structure “always worked ”.

This article is an opinion piece for what file structure has worked best for me and my teams after our own trial and error. You are more than welcome to adjust it for your own use case. I am interested in maintaining this article as a living document of what has worked best for the React community, under what conditions, and why. Please share your file structure discoveries in the comments below.

This is only an opinion piece for what file structure has worked best for me after several trial and errors. You can also use my structure just as a skeleton to build more on it. If something works for you and it is not mentioned in my article please feel free to share your ideas in the comments below. I will make sure to respond to them.

First I will show you my structure and finally, go on to explain how each section belongs in the structure.

My project structure:

/*(your_project_folder)
├───node_modules
├───public
│   └───static
└───src
    ├───actions
    ├───assets
    │   ├───icons
    │   ├───js
    │   └───scss
    │       ├───animations
    │       ├───components
    │       ├───errors
    │       ├───layout
    │       ├───platform
    │       ├───profile
    │       └───utils
    ├───components
    ├───layouts
    ├───reducers
    ├───services
    ├───store
    ├───utils
    └───views

Explanation:

First, the general structure:

• node_modules is where packages installed by your package installers like npm or yarn will be.
• public directory is used to keep all your static files. If your JavaScript application, that is the files in src, do not require certain files then keep it here.
• src directory comprises of the meat of your application as this is where all your dynamic files should reside.

Second, the `src` directory in detail

• views is the directory in which you keep all your pages or unique views that make up your site. For example, the checkout view, or the dashboard view. In a few words, all the unique views that your website has.
• components is like an ancillary to views directory as they consist of all the views that are common to one or more views in the viewsfolder.
• layouts consists of all the layout files used on the website. Thus all the files create the visual backbone of the website should go in this directory.
• assets consists of all the images and stylesheets that are used by the JavaScript application.
• utils houses all the helper functions that can be used globally throughout the application helps you to keep your code DRY (Don’t Repeat Yourself) and enjoy all the benefits that DRY code comes with: Maintainability, Readability and Easy Reuse.

Directories you should have then you use a state management tool like Redux

The following folders are all a direct child of the src directory.

• actions stores all the action functions that are used throughout the application to carry data to your store.
• reducers stores all the reducer functions that are used by the application to determine the changes to the application’s state.
• store basically the file or the set of files which store the whole state tree of your application.

More on the `views` folder

└───views
        ├───auth
        ├───errors
        ├───platform
        ├───product
        └───profile

The views folder should be the largest folder in the entire directory as it houses all the views that make up most of the frontend of the application. Thus I feel I should explain a little more on how I organize this big directory

Although the naming of different components from here hugely depends on you still I would suggest you to follow the rule of keeping the subdirectory depth at most 1 as or else you will have a hard time to just find a file and thus even code reviews will be tougher.

So now let’s move on to my the rules and methods I use to organize my views folder:

• I arrange all the views under big features that are used by the application. For example, auth , profile , settings ,etc..
• Another important thing that has helped me a lot along the way is having an index.js file for each feature. It houses the export statement for the topmost component of that feature. This is really helpful as the code is often changed during development and this method increases the maintainability of the codebase. As unlike before the index file always points to the topmost file no matter how the files of a certain feature is changed.

The stylesheets

└───scss
       ├───animations
       ├───components
       ├───errors
       ├───layout
       ├───platform
       ├───profile
       └───utils

I believe in keeping all the sass files in a completely different file rather than in each feature directory as it helps one to find the files as they are in one place. Making it easier to make changes to several files at once easier.

I store the sass files as assets/sass directory. I also use the same logic there as in views, that of separating the files according to feature and creating an index.js for each of them also I create separate files for components , utils , layouts each.

A few additional things that I do is:

• Create two files the global.scss and the index.scss directly under the sass folder. The global.scss file stores the styles that are global to the project like background-colour of the body or the font-size and font-family of the application.
• I also keep a separate folder for animations as these animations generally get used as simple CSS helper classes to animate elements throughout the project.

Conclusion 🔥

Most of the organization depends upon you but on using these principles as the basis of your file structure organization should help you in the long run as it has helped me time and again.

If you have any further questions or great inputs on the above topic, please leave them in the comments below.