How to Organize Your React.js App Folders
How you structure your React.js app has very little official guidance. Start with one folder and expand as you go they say. However, how it is supposed to look like? As of now, there were thousands of ways. Over time you see some patterns emerge that works and I would like to share some of them with you.
Let's start with the typical one folder to put them all. Although it might work well for a very small app, it is obviously not going to scale very much. Even with a small app that has more than one simple view. However, it does bring one interesting point. How many files a folder needs because you feel inefficient to navigate between them?
If you're coming from the Java world, you might have the reflect to separate all your components within a separate files and never have more than a 5 or 10 files because you begin to split them up again. One single folder versus many many folders are both extreme and like most things, balance is up the essence. The first would be complete chaos to navigate. When something is complex, it is always better to strip it down into small separate chunks and we don't do that, we get lost and confused. However, when all you have is tiny chunks, what you got is a puzzle that is impossible to understand. We need to chunk it down, but into pieces that are big enough to make sense. I don't see a problem with 25 or even sometimes 50 files in the same folder but don't take that number for granted. Use your own judgment.
Split By Theme & Domain First
The best way to make sure your code is easy to understand and change is by splitting it by chunk. A lot of people are splitting it by technology. This folder has components, this one utilities, this one Redux reducers. While this can be useful, it is wasting your time more than you think and let me tell you why. When you are developing a new feature, you will most likely touch a lot of those tech concerns. You will touch the visual part, you will have to call APIs and so on depending on your stack. However, to be able to quickly understand the code and change it, if it is split by tech, you will need to touch a file in all those directories. What if instead you had all the files you needed for that feature into a single folder? Would that not be a lot more efficient? The code that changes together should live together. I don't remember the last time I had to rewrite all the API calls. However, when I'm adding a feature there is always one I need to use.
When you split your folders by theme & domain, you will open your source code and the first things you will see are names your user cared about. For example, a social media app might have the following folders:
No Nesting And Minimum Coupling
When you start to split your components by theme of your domain, you might feels good. The amount of files will grow over and you might be tempted to add subfolders. Try to avoid that as much as possible. Now you have to ask yourself am I splitting that folder into two? If the answer is yes, instead of nesting your files into a subfolders, you should create a different module. You can have 50+ different modules in the same folder. Instead of nesting, if you're app is getting too big, you can split that module folders into subfolders, again using themes from your app domain instead of technologies. However, do not nest within a module. You don't want that mess.
You want to treat each of those folders as independant modules so that when you can change something, it does not influence the entire app. The change will be predictable and will not break something else because it has coupling with 50 other things you don't know about. This is also true when you're splitting your big modules into two smaller onces. They now should be treated as two different modules that should avoid coupling with the other as much as possible.
Define Your Public Exports
One last thing I love to keep things organized is by defining what is public from each folders. Just like a module on NPM, some of the components are to make it works, and only a few of them are meant to be used. To make it clear, the best approach is to export into the index file what is public. When you import from another module, you only import from the index file, never from a file directly. This is now considered your public exports. I would also argue that it is better to write all your tests by using those public exports. It makes refactoring so much easier to do. If you can't refactor the code without refactoring the tests, you don't have tests. You just wrote your code twice.
If you want to learn more about testing, go read Testing React Components With Accessibility Roles.
We will never spam you.