DEV Community

⚛️ Folder Structures in React Projects

Will T. on March 20, 2024

Organizing files and directories within a React project is crucial for maintainability, scalability, and ease of navigation. This article explores ...

Read full post

Chaz Gatian • Mar 21

I use a folder called /pages to signify top level routes, similar to the modules folder. IMO modules is too generic.

Will T. • Mar 21

Sometimes I also use /pages or /features instead of /modules.

Bruno • Mar 23 • Edited

I don't think the statement you wrote on the disadvantages of level 3 is that much of a disadvantage, because any developer who is already working in the project, and also newcomers would still have a better idea of where to look for things if they are in their respective places, which come with a proper folder structure, in my point of view, and the business logic is thus properly defined. I do find it to be the way to go for big projects, though. Really great naming for the different parts of a React project!👍

Will T. • Mar 24 • Edited

Yeah, I had to come up with at least a disadvantage anyway, so... Having clear business concerns takes a bit more mental effort initially, but is not a real disadvantage.

Bruno • Mar 24

Yes, that could be, especially if you’re a new dev in the team, that can be a great challenge at first, but once you know where to look for things by business concern, it will be easier to find the individual piece of code you are looking for. Good article in general! 👍 but found it funny when you said you had to come up with at least one 😄 sometimes there are things which we really want to find a disadvantage, but we get disappointed 😅

Will T. • Mar 25

I figured it might be arrogant to say something that I came up with to have no drawbacks whatsoever 🤣.

Simran • Mar 27

These examples are very "Redux" focused and outdated. No one creates folders like actions or reducers anymore. All new projects are trying to stay away from Redux and adopted other state management solutions like "Zustand". Which simplified not just state management but made folder naming more sensible.

Will T. • Mar 28

I agree that no one really uses Redux if it's a newer project anymore. I also use Zustand/Valtio and React Query in my projects, and I think Redux is redundant and should be discouraged. Nevertheless, it's my/our opinion since a lot of projects out there are still using Redux and some people still find it useful.

My bad for not noticing that those folders appear too often in the examples. Thanks for pointing out the details.

Tin Tran • Apr 19

How do you know Redux is outdate?

Abel Lifaefi Mbula • Apr 12 • Edited

Thank you for sharing.
I'd suggest giving a brief intro for different directories, unless it's so obvious. You can see the Gatsby Project Structure.

Will T. • Apr 13

Thanks. That’d be a nice idea for the next articles.

steve • Mar 22

Nice differentiation. I like 3.
There is no reason reused components across modules can't also be shared in a universal folder.

Also I prefer not to clutter my code with test files and reproduce the same folder structure for tests but in a separete __tests/ folder.

Will T. • Mar 25

I used to work on projects that have a parallel __tests/ folder that mimics the same folder structure. I think that's also a good way to organize tests.

user_af5d39430a • Apr 6

As someone who is OCDAF … I truly appreciate this post because when I started I could not find anything about how to structure my projects! I ended up just going back and forth and then projects got too big and it drove me mad!

Will T. • Apr 7

Oh, an OCD fellow :)). I also feel irritated when I encounter a problem again and again, so I often spend a lot of time trying to solve it once and for all.

Arthur Henrique • Apr 22

For level 3 forward, I'd also consider split each module in its own package, maybe through a monorepo approach; Even because a micro front-end solution could soon help into increase organization for a project that is rapidly growing in complexity

Will T. • May 1

That is also a very reasonable approach, maybe we can even call that "Level 4".

Daniel Dallimore Mallaby • Mar 24

Nice post

I usually use
/components ( all the generic one)
/pages ( contain specific component, Page hooks, Styles)
/config
/lib ( contain generic hooks, rtk, all the logic stuff that Is not a component)

Will T. • Mar 25

That's similar to the "Level 1" folder structure that I mentioned, right?

Mike T • Mar 26

The level 3 organization reminds me of what Angular did already. Ultimately as long as there is a systematic way of putting files together that is coherent any dev should be able to find what they need with little trouble. I think that should be the takeaway.

Will T. • Mar 27

Yeah, the important thing is consistency, no matter what you choose to go with.

Adaptive Shield Matrix • Mar 23

For any real projects (not hobby ones) - Level 3 is the only way.
Every other way will be a mess starting starting with 30-100k lines of code.
You may just skip the "modules/" folder entirely and make it more flat.

You always want files with in the same bounded context (term from DDD - Domain Driven Design) to be near each other. Grouping files/folders by domain first is always better than the technical separation.

Will T. • Mar 25

The "Level 3" folder structure is heavily inspired by DDD. FYI, I actually took the idea from DDD.

official_dulin • Mar 28

Can you clarify the differences between services and helpers for business logic？

Will T. • Mar 28 • Edited

Hi, thanks for the question.

The /services folder mainly contains more complex logic, and it'll most likely use the logic from the /helpers folder. Let's say you want to implement the employee search functionality in the FE side. There can be a lot of fields, and the fields can have different matching logic, and some fuzzy search might also be required. That can be considered complex logic already, and it should live in /services.
The /helpers folder is mainly for very simple, mainly one-liner logic, e.g.

export const isAdmin = (user: User) => user.role === UserRole.ADMIN;

If you don't want to have the /helpers folder, it's fine to have all the logic live in the /services folder as well.

When I think of the /services folder, it does not only contain pure business logic but can also act like an orchestrator. Meaning it can call functions from the Persistence layer (e.g. network requests from the /api folder, or interacting with localStorage in the /lib folder, etc.) to get the inputs needed. The /services folder is like a facade (in the Facade design pattern], which I'll talk about more in one of my upcoming articles. Please look forward to it.