DEV Community

How I structure my React projects

Lars Wächter on August 31, 2021

This post was originally published on my blog. It's been quite a while since I wrote an article about how I structure my Node.js REST APIs. The...

Read full post

Val Redchenko • Sep 2 '21 • Edited

Hi, thanks for sharing. This might sound opinionated but my personal preference is to stick to Next.js way of doing it, unless there's a specific and significant reason to deviate. Firstly - looking for the "best" way to structure a project is not a quest where an absolute truth can be reached - nor is it likely inventing anything beyond what's already out there - we've been at it for a while already, and all the principles for good code organisation have been formulated decades ago and apply cross-language. Additionally consider that Angular has an endorsed convention that's important for Angular-specific reasons, Vue.js has Nuxt.js that pretty much nails it, same as Next.js for React - you get a lot for free from just sticking to what they do. And if I was to inherit one of your projects - figuring out your private and undocumented organisation system would add noticeable overhead when first mentally indexing the codebase. If it was just common Next.js - I already know what stuff goes where and would onboard quicker, and depending on project size, complexity and time in development - my time savings would grow in significance. When working in a team - everyone might have slightly different tastes - having in inherent convention from outside the team that's well known and documented negates the need to seek compromises internally. I strongly suggest you should adopt Next.js straight away - I wager you'd come to appreciate it within 2 days of switching - speaking from personal experience here.

Lars Wächter • Sep 3 '21 • Edited

Hi, thanks for your feedback first of all :)

stick to Next.js way of doing it

one of the most frequent feedback or "criticism" I get for this article is that I should rather stick to Next.js. I've never used Next.js or even took a closer look on it before but I have no doubts that it has a better folder structure / code organisation, higher scalability, cleaner conventions or whatsoever. Nevertheless, that's actually no real reason for me to abandon the idea of building an own React project structure.

I guess that's just my personal opinion but I'm not really a fan of statements like "you should rather go with framework X than framwork Y". If I was a beginner, which this article is written for, one of the last things I'd like to hear when learning a new programming language / framework is something similar to this.

Moreover, I think you can learn quite a lot by implementing your own folder structure, even if it might not be the best one or nothing like an "industry standard".

Firstly - looking for the "best" way to structure a project is not a quest where an absolute truth can be reached - nor is it likely inventing anything beyond what's already out there

Absolutely, that's why I mention it at the beginning of the article :)

And if I was to inherit one of your projects - figuring out your private and undocumented organisation system would add noticeable overhead when first mentally indexing the codebase. If it was just common Next.js - I already know what stuff goes where and would onboard quicker, and depending on project size, complexity and time in development - my time savings would grow in significance.

I might be wrong (because I never used Next.js) but for me it's hard to believe that there's such a huge difference regarding the architecture between a Next.js and "vanilla" React application that ends up in a significant time saving while getting familiar with the code. Depending on the project size the most time consuming part is the process of learning the project domains in my opinion.

Anyway, thanks for you suggestions. I'll definitely check out Next.js in the future.

Chaim Krause • Sep 3 '21

Standards are best to follow when working on a team project. Where there are no standards, conventions should be followed. Here, if you are using Next.js, then you should use their conventions. Agreed.

Rafael Rocha • Sep 1 '21

This is a good enough structure that I follow in a similar way for my personal or small scale projects. For webapps that are going to potentially be touched by several developers I find quite useful to have feature folders to apply some kind of bounded context to those components and logic. Having a shared folder for example for a base api client or some utility functions that aren't feature dependent would be the point of re-use.
I tend to work in an environment where most components are complex compositions of atomic components coming, for example, from a component library.
In any case nice reading and if you just keep your frontends small and orchestrate them with SSR or more recently with module federation it can boost scalling capabilities.

mungadunga • Aug 31 '21

Amazing!

Lars Wächter • Aug 31 '21

Thanks, glad to help!

dotorimook • Sep 2 '21

Thanks for sharing!
Could you explain the difference between stores and providers and the reason why providers is in utils folder and stores in root separately?

Lars Wächter • Sep 3 '21 • Edited

stores are global states across the whole application managed by zustand, which is a state-management library.

providers are actually React Context providers. I use them mostly to make the state management for "large" pages with a deep component tree easier. I guess you could also put them into the directory of the according "page" component.

So stores are accessible from anywhere within the application while providers are mostly used for some specific pages.

dotorimook • Sep 3 '21

Thank you! Your explanation was very helpful to understand!

Lesley van der Pol • Sep 2 '21

Interesting structure! I also use something similar to this, but it always gets a little questionable once a project grows. What does your structure evolve into when you have component A, and component A has custom styles, hooks, utils and tests?

Lars Wächter • Sep 3 '21

In this case I would put all the files that belong to the component into one directory. So something like this:

├── components
│   ├── User
│   │   │── Card
│   │   │   ├── Card.css
│   │   │   └── index.js
│   │   │   └── test.js
│   │   │   └── useCard.js

Daniel Klimuntowski • Sep 3 '21

Looks well structured.

Personally, I wouldn't put all tests in a separate folder, as I'd have to recreate to whole src structure inside of it, unless I'd stick with a tons of test files. I'd leave test modules next to prod modules, e.g.:

- components
-- MyComponent.tsx
-- MyComponent.test.tsx
- utils
-- strings.ts
-- strings.test.ts

To me the above example looks cleaner than:

- components
-- MyComponent.tsx
- utils
-- strings.ts
- tests
-- MyComponent.test.tsx
-- strings.test.ts

OR:

- components
-- MyComponent.tsx
- utils
-- strings.ts
- tests
-- components
--- MyComponent.test.tsx
-- utils
--- strings.test.ts

Lars Wächter • Sep 3 '21

In the article I mention that I put components and their accordings tests into the same directory.

The "global" test directory includes tests that do not belong to certain components :)

Shazebict • Sep 5 '21

Thanks for the article it was very helpful. Shazebict Offers Best Support Services for Companies within dubai abu dhabi sharjah uae for all your Software, Hardware, Network, Backup, Recovery, CCTV, Access Control and Accounting Software related IT requirements.

Ian Wijma • Sep 3 '21

This is super close to what I've started using over the years, its a great structure.

Soumava Banerjee • Sep 1 '21

I also create my structure like this, but I create a separate UI folder within components that hold my Card, Buttons and other common components. I skip this part when I use a UI library like Material UI or Chakra UI.

Lars Wächter • Sep 1 '21

Actually, I also use an UI component folder for more generic components like Buttons for example. I just didn't mention it in the article to keep things simple. Might be a good idea to add it.

Ilie Bogdan • Sep 2 '21

It's beginning to look a lot like next.js :d except next has server side code

Lars Wächter • Sep 2 '21

That's possible, I never used Next.js until now :)

Ilie Bogdan • Sep 2 '21

You should really give it a try. As a react developer, I'm sure you'll fall in love with it!! :D
Have fun!

And great article btw, I'm sorry I didn't mention it before :D

Mohammed Ashfaq Ahmed • Sep 3 '21

I was looking for this from so long. Thanks for the article!!!
Amazing

ebnibrahem • Sep 2 '21

thanks for sharing.. Next.

what's best?

home > components > headerComp.js
profile > components > accountComp.js each page has child folder named components.

components>home>headerComp.js
components>profile >accountComp.js

One folder named components contains all app components.

Lesley van der Pol • Sep 2 '21

I personally think it is always good to try and have a good separation of concerns. I think you are talking about page specific components? Those don't belong in the components folder, unless they are reusable by other pages. In this case I would personally opt towards having a components folder within your page folder itself.

Everything that is reusable however could and should go into the generic components folder.

Marcelo Rafael Gonçalves • Sep 3 '21

Nice

Ali Nazari • Mar 17 '22

What is the difference between components directory and pages directory? It seems they contain similar components.

mesfin • Sep 3 '21

Interesting post, Thank you!

jmunozl • Sep 2 '21

Very good contribution

Kamil Paczkowski • Sep 3 '21

I needed a thing liken that, great post, keep it up!

Pratik Saria • Sep 2 '21

Its a very good structure thanks for writing this article.

MrMyatNoe • Sep 3 '21

Thank you for sharing

Asep hamdani • Sep 3 '21

nice bro

Chadrack kyungu • Sep 1 '21

interesting post

kishoreandra • Sep 1 '21

great post lars .... thanks for putting up :)

Yogesh Rathod • Sep 1 '21

Nice

lindellcarternyc • Aug 31 '21

Very nice!

Paras 🧙‍♂️ • Oct 30 '21

Great Article on structuring react projects. Loved it :)

HRITHIK GOSWAMI • Sep 2 '21

Thanks for the information

ak_zm • May 10 '23

Hi, can anyone explain to me how we can create an api service? like api/services/job.js and user.js in this article

Lars Wächter • May 12 '23 • Edited

A service is in this scenario a simple class with static methods for fetching/posting data and so on. Something like this:

class UserService {
  static fetchAll() {
    return fetch(/* ... */)
  }

  static fetchById(id) {
    /* ... */
  }
}

You don't have to use a class. Another way would be to create multiple functions and export each one of them.