What you need to know about react project structure

One of the most common question that pops up when learning new programming frameworks (or library in reacts case) is “How is the project structured?”

Most of the time the answer depends on the standards the creators or the community of the framework have set.

Since react is actually a library and not a framework the flexibility is endless, but best practices have arisen throughout the react community.

Why does it matter

When working solo it might not seem as apparent but the project structure is a very important component primarily for scalability but also for productivity.

When a solid project structure is set you (and other project members) take significantly less time looking around the codebase and deciding where to add new components.

That doesn’t mean though that you should spend more than 10 minutes deciding on the project structure, after all you can always change it based on your needs!

Common structures

The below images show some of Troosh’s screens that we will use for explaining the differences between the structures.

Presentational / Container

This can also be called grouping by file type. The presentational / container structure most commonly splits the views from the business logic.

The presentational folder in this case would contain all the components that are visually represented to the end user including styling files. These usually do a lot of DOM manipulation. In the above case we would create presentational folders for each UI component. Some UI components would be Home, Search, Post, Category, Project (third image).

The containers folder would commonly include data fetching, contexts, wrapper components and other complex logic. Usually DOM manipulation is not present in container files. We see a lot of data in the above images so for each UI components that contains data, we would create another <Component>Container folder like HomeFeedContainer, CategoriesContainer, ProjectContainer etc. This naming notation is not standard, just my personal preference.

There is a great article by Dan Abramov going in depth on this structure.

Grouping by features

This is the one I personally like and use the most, mostly because I think it makes more sense logically.

The logic is pretty straight forward, basically there is one features folder which contains a subfolder for each feature in the app. For example chat, notifications, user profile etc. would all be different folders under the features folder. On every feature folder all the required components and static files are included. In the above example we would have some directories like Post/PostAvatar, Post/PostBody, Categories/CategoryTitle etc. under the generic features folder.

There is a caveat to this one, the is not really an objective way to specify something as “feature” so it might not make sense to everyone. The great benefit of this structure is the level of code discoverability it provides.

General abstractions

The above structure only covered the react stuff, but on a react project (well on every project) technologies outside of react might be present, so how are these handled?

• Static files are usually under a single “assets” / “public” / “static” folder which lives at the root of the project.
• These functions might do not have a direct correlation to the project and might be of general use. An example of this would be a date formatter or a currency converter function. These usually go under a “utils” folder.
• It’s very common for react projects to depend on other popular technologies. About half of react project use redux (at the time of writing this). In this example redux uses reducers and actions which will probably take a lot of space. Some people like to create a “store” folder with “reducers” and “actions” as subfolders. This concept is not exclusive to redux. Any other technology that introduces lot’s of new concepts is usually handled this way.

Dont’s

• Try to avoid nesting. No one likes opening multiple folders to find one thing, this is actually counter productive.
• Don’t overthink it. When starting out, it doesn’t really matter what you choose (unless you start out as a big team). When the time comes abstraction will start to feel natural or even a necessity.

Conclusion

Lot’s of concepts have come up by the community and even more will come up in the future. Despite this there is no best option, choose what you like (even said by the react team)!

It is a good idea to be aware of these structures even if you don’t use them initially. This will make it easier for you in the future to start the abstractions when the time is needed.

Want to learn more about react? Dimitris Stefanakis is a react / react native mentor on Troosh and creator of this article. Be one of his first students by subscribing to our newsletter on Troosh and get notified on our launch!