DEV Community

Discussion on: A Better Way to Structure React Projects

Collapse
gruckion profile image
Stephen Rayner

Having a single folder full of components just makes me think you haven’t worked on a large project. Even if you divide it into AMO folders you still end up with hundreds of components.

The better solution is the feature folder layout.

Collapse
joelbonetr profile image
JoelBonetR • Edited on

We usually make something like that:

having some styling globals 'variables.scss, common.scss, modals.scss, fonts.scss, colors.scss, accordion.scss and so' organised on semantically understandable directory tree.

Then each component has it's own scss where you import (@use) the necessary globals.

We find this was as more suitable for big projects but i'm not sure if it's the best way yet, how do you manage it?

Collapse
krisguzman_dev profile image
Kris Guzman Author

I have actually used this with large teams pretty successfully.

I'm not against a feature folder structure, I think it works fantastic in conjunction with an atomic design structure. There's no one size fits all.

The problem with feature folder layouts is that all components become tightly coupled with their domain context, which works okay for slow changing systems, but not so great for fast paced startups.

Atomic design takes way some of that domain specific context, which has its pros and cons. What I personally do is a combination of what you mentioned, a feature folder layout, along with an atomic design structure for more reusable components.

I found that even with devs coming in and out of a project, it generally works fine and keeps things organized. When we build out storybook for a component, it's easy to keep it in sync with what the design team has, and easy for the design team to audit the current state of the UI.

Perhaps my article came across as a bit dogmatic, but I'm aware that a little controversy usually gets a good conversation going :)