---
title: "Comment by psanchezmvelarde on \"A Better Way to Structure React Projects\" | Hashnode"
description: "This makes sense when you are building simple applications, but when you project involves a lot of business logic sometimes it is not that easy to abstract comp"
url: "https://hashnode.com/posts/a-better-way-to-structure-react-projects/5fc7a9aa6819c54efdf2e1f2/comment/5fc8ab41820f7e5bbbc2a7c7"
---

[Discussion](https://hashnode.com/posts/a-better-way-to-structure-react-projects/5fc7a9aa6819c54efdf2e1f2)

Comment [A Better Way to Structure React Projects](https://hashnode.com/posts/a-better-way-to-structure-react-projects/5fc7a9aa6819c54efdf2e1f2)

[psanchezmvelarde](https://hashnode.com/@psanchezmvelarde)

[Dec 3, 2020](https://hashnode.com/posts/a-better-way-to-structure-react-projects/5fc7a9aa6819c54efdf2e1f2/comment/5fc8ab41820f7e5bbbc2a7c7)

This makes sense when you are building simple applications, but when you project involves a lot of business logic sometimes it is not that easy to abstract components. I usually use an approach of structuring my components hierarchically, separating UI common components, of course. This way parent components have their own directories with their specific children components inside.

What is your opinion on this method?

Nice article any ways! Good job!

[Kristopher Guzman](https://hashnode.com/@kag359six)

[Dec 3, 2020](https://hashnode.com/posts/a-better-way-to-structure-react-projects/5fc7a9aa6819c54efdf2e1f2/comment/5fc8ab41820f7e5bbbc2a7c7#reply-5fc8bf4f6241335dca59500f)

I'm glad you mentioned this! Abstraction certainly is difficult at times. Even further, sometimes there are components that only exist in 1 place, and it doesn't make sense to abstract them.

What I usually do is one of two things:

A. Create a sub "components" folder in the "pages" folder. These components ONLY exist within that page, and it makes it very easy to differentiate between shared components and one-off components.

B. Create a "domains" folder, which contains business logic heavy, not-so-reusable components. This is much like the approach you mentioned.

I think I did a poor job of explaining how to scale this type of project structure, but I plan on clarifying all that in a "part 2" article. Thanks for the feedback!