2 Best Practices For React File Structures
By: Dan Brioli
Tags: Files, Front End Development, React, Web Development, Development

There is no by-the-book best practice for your React app’s file structure. Ultimately, these decisions are based on what works best for you and your team. These two tips are what finally helped me make sense of the chaos that is managing React components and assets in my IDE.

Tip 1: Use This Versatile Folder Structure

If you generate a new React app — from create-react-app, for instance — you will see everything that was created is just stuffed into the src folder. That’s fine for your app when it’s first created, but it gives you no insight about how you should ultimately structure your app’s files!

Here is the solution that I use to make React file structures actually make sense:

src

.assets

..images

...image1.png

...image2.png

..styles

...global.css

...package.json

..fonts

...sansSerifExample.woff

...serifExample.woff

.components

..App

...App.css

...App.js

...App.test.js

...package.json

..Login

...Login.css

...Login.js

...Login.test.js

...checkmark.png

...exclamation.png

...package.json

..Button

...Button.css

...Button.js

...Button.test.js

...package.json

.utility

..registerServiceWorker.js

..utilityFunction1.js

..utilityFunction2.js

Depending on the project, you may drift from this general outline, but I’ve found it to be the best solution so far. Here’s why:

First, it’s well-organized and easily understood.

Under the src folder, we have child folders for assets , components , and utility functions.

Under assets , we have child folders for global CSS files, image files, and fonts. The assets folder is for any fixed asset that will be used globally within your project. These may take the form of fonts, branding images, color or pattern swatches, CSS that needs to be applicable across the entire project — whatever non-component assets that you need to have global access to go here. You may find it helpful to store other fixed assets here as well if your project has unique categories that aren’t listed in the example above. Just group them in an appropriate child folder and you’re good to go.

There is also a utility folder, which is used to store utility functions that are used across the project — you might also know these as helper functions. This is a great way to keep track of the additional functional utilities you have created for your app. I often find myself copying these files wholesale from one project to another — I know I will need them eventually, after all. Centralizing them in one location saves me time not only when working on this project, but when working on future projects, too. This folder provides a known location for all of the custom utilities that I might want to duplicate elsewhere.

We also have a folder most devs using React should be very familiar with — a components folder. As the name suggests, this is for components… But not just their individual js files! For each individual Component , we will create a unique child folder under components with the same name as the Component .

Within each named Component folder, we store each file that is associated with the Component :

A js file for the Component ’s code.

file for the ’s code. A test file for any individual testing of the Component .

file for any individual testing of the . A CSS file for the Component ’s custom styles.

file for the ’s custom styles. Any images or other assets that are only used for this particular Component .

or other that are only used for this particular . And a… package.json file? Isn’t there supposed to be an index.js file or something?

Often in these types of React file structures, you will see an index.js file. Sometimes, index.js is simply the Component ’s JavaScript, whose default export is the Component itself. Other times, index.js just import s and return s the Component itself. It’s a bit of connecting things together that serves no real purpose other than allowing you to import your Component using only the folder name. While that’s a nice quality-of-life improvement, using an index.js file has plenty of other issues — most of which seem to center around the future, when you inevitably have to refactor something.

Believe it or not, you’ve had a solution to these issues in front of you this entire time, and you just didn’t know it… That solution is webpack.

Tip 2: Take Advantage Of Webpack For Indexing Files

You’ll notice a package.json file in each Component ’s folder. This is the perfect solution to the index.js problems I just mentioned! All you have to do is create a package.json file for each Component , and list its “main” value as the file that has your primary Component code in it. So in the Button Component folder above, its package.json file has the following JSON:

{

“main”: “Button.js”

}

…and that’s it! That’s all we need to add to the file to make sure we are handling our import properly! Webpack handles the rest for us. It’s a module bundler, and we’re using it for the thing that it does best — directing import statements to the right places! It’s just saying “Hey, guess what? When you import this Button folder, the main thing you will be importing is Button.js!”

So by using a statement like import Button from ‘../Button’; with our package.json solution, the outcome will be the same as if we had used import Button from ‘../Button/Button.js’; or import Button from ‘../Button/index.js’; with our old index.js solution!

It’s a small adjustment, but it helps fix issues with correcting your import s in the future when you rename Components or have conditional import logic. Webpack gives you a nice, standardized import structure, which will definitely save you headaches in the future.

And I didn’t mention this before, but the same can be done for other folders and files, too! In the src/assets/styles folder, there is a package.json whose JSON is:

{

“main”: “global.css”

}

And import ing it in a Component is as easy as typing import ‘../../assets/styles’; !

Thanks For Reading

The above are two best practices I started using a while ago, and since that time, they have made handling React file structures an absolute breeze. The mental model I have of my code is consistent across projects now, and refactoring has been made a little bit easier by utilizing webpack for bundling files within folders properly.

If you have any tips for React file structure best practices, be sure to let me know! Now go out there and fix your folders!