The best folder structure for your project!
Let’s talk about why the title of this article is clickbait. Why there is no better or worse file architecture and why you shouldn’t trust articles that offer you such.
“How I structure my React project”, “CSS Architecture”, “How to create a modern front-end architecture,” and a lot of similar articles that I read look pretty much the same. The authors talk a lot about their many years of experience, the number of projects where they use their architecture, and how life has improved with all these files and folders. Well, how can you not believe those people?
Every such article makes me sad. But not because the authors are mistaken and their folders are inconvenient, but because this is a highly subjective, unimportant question that causes a storm of anger and controversy.
How do you use your IDE?
Perhaps this is the most crucial question in the “perfect folder structure” topic. Personally, I like to use a file tree in the sidebar or links in dependencies. But you may prefer a quick search by filename, breadcrumb links, search for keywords, feature/component names, or just to keep all files open. This variety of options destroys any, even the most convenient architecture — it will never be suitable for everyone.
For example, I don’t like deep nesting because opening four folders in the sidebar to get to the coveted index.js is a pain. However, when I use dependency links, it gets easier. Search by filename is also not affected by folders structure, but I never got used to it.
It only seems that /components/forms/login/components/ is the best nesting for all and anyone.
Believe me, it will be inconvenient for someone.
As well as the only /components folder, which will cause questions for most developers: is it just to put everything in there? And even if it’s a whole page? And even if it’s a small component? Thoughts on “how to improve this too simple architecture” can take quite a lot of time, energy, and motivation.
How much do you like to follow the rules?
Let’s be honest, I love when everything is according to the rules and in good order, but only if it’s my rules.
The more limitations and regulations, the more difficult it is to work with the project because you have to memorize everything, not forget, and the most importantly — use it.
Rules written in text (or even worse, just spoken) and controlled by teammates during code review are inconvenient and provoke conflicts. Therefore I came up with the following strategy:
Everything that doesn’t have automated code review — doesn’t matter.
Of course, this doesn’t apply to the review of algorithms, abstractions, and data flow, which should carry out. It also doesn’t mean that the team can turn the project into a dump and write each new component in a new way. But there is a big difference between automatic style checks and manual control of any developer action.
Believe me, I have hundreds of rules for naming files and folders in my personal projects, but in a large project with a large team, I will create files exactly as they were created before me.
Of course, you can persuade your team to rewrite everything “correctly”, but first answer those questions:
- How much time will you spend on this?
- How difficult will it be for your team to move to a new architecture and get used to it?
- Do you have the patience to follow this transition and control violations of your rules?
- What are the benefits of your changes?
- How long will your architecture live without you if you leave the project?
The answers will help you realize the importance of your decision.
Significant changes and new rules are easily implemented only in personal projects. However, when we talk about a team of several people, the complexity of changes increases several times. Therefore, it’s not about telling how to do it correctly but also about being responsible for your decision.
What about your abstract thinking?
When we look at a complex structure, our brain tries to decompose it and identify patterns of repetitive elements. It is easier to grasp information this way. Therefore, when programming, we use abstractions.
Unfortunately, developers really like to create abstractions guided only by the DRY principle. And it says a lot about the level of abstract thinking of modern specialists.
Just because two components are similar doesn’t mean they have to be in the same folder.
For example,
let’s create a folder for the login page — login and put all the components in there.
But what about a popup dialog that also has a login form?
Should we put it in the same folder?
But the popup isn’t on this page. It’s in the header on all other pages.
Should we put it in the modals folder with all other popups?
But how then is it better to reuse the common form?
Move the form to the forms folder with all other forms?
But then the integrity of the pages and components folders is falling apart…
As you can see, a leaky abstraction creates more questions than benefits.
Abstractions are complicated, and good abstractions are an almost unattainable luxury in modern, fast-growing, and ever-changing projects. Therefore, the best advice is to simplify, repeat, don’t group everything that gets in your way. In most cases, this is an unnecessary excess that complicates your project.
Otherwise, you, like me, will be ashamed of all those folders forms and modals, utils and services, structures like components/common and other solutions “for the future”, since someone continues to suffer because of those or hopefully doesn’t use them.
Instead of a conclusion, remember all the “best rules” for the project structure you have used throughout your career. I’m sure there will be several: separate HTML, CSS, JS into different folders; separate the components and everything related to them into folders; separate “smart”/”stupid” components, pages, interfaces into different folders. That’s just part of my list. And what is yours?
In my opinion, rules that are constantly changing cannot be rules. So you shouldn’t follow them thoughtlessly, driven by hype. At the same time, you shouldn’t create standard utils, components, and similar folders out of habit. Instead, focus more on what you are doing and why. Why any solution is convenient for your project or vice versa doesn’t work for you.
Answers to those questions are the foundation for a good project architecture.
Thanks for reading so far!
See you next time! 🤹🏻♀️
