Live data from Hacker News

How to Structure React Projects

reactjsnews.com

41–45 of 45 posts

Re: How to Structure React Projects

#41

Organize directories per-feature. What is a feature? Think of it as organizing by end-user value delivered. For example, "appointments/", with subdirectories "appointments/recurring/" and "appointments/import/" for those two really complex bits. Don't make sub-directories by kind (screens/, controllers/, directives/, views/, styles/, etc), instead encode the kind in the filename (make it a suffix). Don't end up with…

Problem is when one component is used in two or more places. Then it goes in the dreaded "common" directory - a roach motel where files check in but never leave. Also the boundary for what a "feature" is, is likely fuzzy. I haven't seen a large project yet that successfully addresses these issues.

Recognize it and rock it. Meaning, don't be afraid to refactor it and take advantage of it.

Of course you will end up having common folders, the trick is to have more than one and at the appropriate level. Sometimes you need a common folder between a few close-but-not-same components. Sometimes you end up deciding to reuse that common folder elsewhere, so you "promote" it up a few levels.

Other names such as "shared" or even "service" can be used, as long as you put big related pieces in subfolders underneath.

Recognize when things get messy with common folders and refactor then. This is the "trick", so to speak. You have to recognize "our common folders are starting to become a mess" as valid technical debt, because the team will keep having a progressively harder time finding the correct code.

Re: How to Structure React Projects

#42

I'm not in tune with the whole web thing, but nothing says overbearing framework like "structure guides" and scaffolding tools. I'm particularly in awe because I just visited the ReactJS site to find out what all the fuzz is about and it makes the bold claim "just the UI", and "the V in MVC".

People impose structure because they like it. You can have a React app in a single JavaScript just fine—it's what I prefer. Incremental search is nicer than jumping between a hundred tiny files in fifty subdirectories in my opinion, but to each their own.

Re: How to Structure React Projects

#44

Organize directories per-feature. What is a feature? Think of it as organizing by end-user value delivered. For example, "appointments/", with subdirectories "appointments/recurring/" and "appointments/import/" for those two really complex bits. Don't make sub-directories by kind (screens/, controllers/, directives/, views/, styles/, etc), instead encode the kind in the filename (make it a suffix). Don't end up with…

I don't get the benefit of this approach -- it's too subjective. Is reset-password part of auth or settings feature? What is the link between routes and features? If I'm on a page and see a bug, how do I quickly find the code behind it if it's not linked to the route hierarchy? The easiest mental model for me is to just map files/folders directly to the route hierarchy. That way you can rapidly build out the overall…

This is where you would also benefit from something like TypeScript. You could just find any use of the component and "go to definition". Or use "jump to class".

Re: How to Structure React Projects

#45

Organize directories per-feature. What is a feature? Think of it as organizing by end-user value delivered. For example, "appointments/", with subdirectories "appointments/recurring/" and "appointments/import/" for those two really complex bits. Don't make sub-directories by kind (screens/, controllers/, directives/, views/, styles/, etc), instead encode the kind in the filename (make it a suffix). Don't end up with…

I don't get the benefit of this approach -- it's too subjective. Is reset-password part of auth or settings feature? What is the link between routes and features? If I'm on a page and see a bug, how do I quickly find the code behind it if it's not linked to the route hierarchy? The easiest mental model for me is to just map files/folders directly to the route hierarchy. That way you can rapidly build out the overall…

>I don't get the benefit of this approach -- it's too subjective. Is reset-password part of auth or settings feature?

Just pick one or the other and be done with it. I'd place it at "auth".

>The easiest mental model for me is to just map files/folders directly to the route hierarchy.

Only files don't correspond 1-1 to the route hierarchy either. The same components can be used in 20 different routes.

Post reply on HN