react-architecture-directory-structure/

[utterances-bot]

React Architecture: How to Structure and Organize a React Application | Tania Rascia

There is no consensus on the right way to organize a React application. React gives you a lot of freedom, but with that freedom comes the…

https://www.taniarascia.com/react-architecture-directory-structure/

[heyslevin]

This is fantastic, thank you Tania! This is great for React newbies like me, helps keep things nice and tidy. Keep it up!

[DmitryVdovichencko]

Great work! Very useful article) For now I working at one of my pet project with React Redux and try to improve structure so this article couldn't have been more relevant. I have a question about smart and dumb components. Do you divide them? As I understand, components look like dumb components) Again, thanks for the awesome article! You did great work!

[minimatrix]

Great article, i architect my react projects in a similar fashion. I have a question though, where do you store your hooks? I usually have a folder dedicated for all my hooks, occasionally with sub folders

[facuxfdz]

I really loved your article Tania! I've recently had a job interview in which I was answered about how I organize my projects in React and I talk about this "traditional" approach of putting all the components together in arc/components, etc. But after I read your article I realized how necessary is to me to change this traditional approach in order to scale my future applications. Thank you so much! (I'm starting in the world of the good practices, and these type of articles really helps me)

[taniarascia]

@DmitryVdovichencko I don't really make a distinction between "smart" components (those that hold state) and "dumb" components (those that pass along props).

@minimatrix Good question, there could probably either be a top level hooks directory, or within utils.

[adarshaacharya]

Awesome article @taniarascia, but I'm quite confused on what to store on services folder I've seen people making api calls from services folder.

And any plan on refactoring take-note app using this approach ? I'm actually referring that project for project structure.

[taniarascia]

@adarshaacharya You could use the services folder for setting up APIs, yeah. I was thinking about refactoring TakeNote, I just need to find the time to do so. I was pretty unhappy with the containers/components setup that it uses and I think it would benefit from a reorganization.

[panayotoff]

'@assets': path.resolve(__dirname, 'src/components'), should probably be '@assets': path.resolve(__dirname, 'src/assets'),

[CalledByThe4ire]

Hey, Tania! Could you please write post about most useful react patterns?

[sathishvskumar]

Hi Tania, Fantastic. Thank You. I've been following your articles so long. This could be one of my favorite as its a good project structure to start without getting confused much. Keep posting if you come up with new ideas.

[risen228]

Sorry, but it's very bad structure. It's better to group code by features. By using this approach, you can prevent trash folders to appear (like components, utils, etc). See Feature Sliced for more information

[unordinarity]

Absolutely non-scalable architecture. Supporting code like this will be unnecessarily expensive immediately after MVP release.

[taniarascia]

@risenforces @unordinarity What are your solutions for a better architecture? Unfortunately the linked article is in Russian, do you have an English language version? The proposed architecture in this article is feature-based, with the majority of the app being in the views folder, and only global/shared components will end up in components.

[jeanfortheweb]

For small projects, like really small projects, a structure like this gonna work kinda okayish, at least when one but not more than two people working on the project. For everything above, it won't scale at all. Just checkout domain/feature oriented structures, there should be plenty of examples available online.

My main concern with this article is that it is features on the react status newsletter, means thousands or even more could potentially think that this is the absolute way to go, which is simply not true.

[taniarascia]

@jeanfortheweb This is domain/feature oriented structure, the components folder is only for global, shared components, while the Redux and views are based on feature. Do you have a solution or link to a better solution?

My main concern with this article is that it is features on the react status newsletter, means thousands or even more could potentially think that this is the absolute way to go, which is simply not true.

I am not sure how anyone can misconstrue this article as being "the absolute way to go" when the article is very clear about being opinionated, and the first sentence is: There is no consensus on the right way to organize a React application. React gives you a lot of freedom, but with that freedom comes the responsibility of deciding on your own architecture. I'm going to show you what I consider to be an intuitive and scalable system for large-scale production React applications.

[porfidev]

I love Tania’s work, but this is not available option when your company reuses modules in different projects, the distribution increase time of reusabilty and it needs locate to every dependency for copy, in that situation a grouped folder cointaining their own components is the best way (for this case), Greetings!

[mikestopcontinues]

A lot of great ideas! One thing though. I prefer keeping all of the code related to a particular component together. For instance /DesignForm/Form.tsx and /DesignForm/FormContext.ts and /DesignForm/useLiveEdits.ts. That way, if I'm working on the DesignForm, I don't have to see the whole file tree expanded. And of course, /DesignForm/index.ts to export only the public interface.

[taniarascia]

@mikestopcontinues That is the intention of this architecture. Your styles, storybook, tests, context, etc. that all relate to the same component would be kept together.

Not the Redux, as that data is global and might be shared across multiple features.

[mikestopcontinues]

Ah, sorry @taniarascia! I misinterpreted where you place the tightly-coupled code. Since I only use context for global data, the /store threw me. I end up putting my global stores with the region of the app they related to. For example, /App/ThemeContext or /PostEditor/DraftContext.

[taniarascia]

@mikestopcontinues Yeah, that makes sense! If your features are very tightly coupled and the context data won't be used in another component that works.

[nathanBrenner]

Great article. It reads a lot like the architecture you find in Angular applications. You can go a little bit further with using index files to establish a convention that those files export the public api of whatever is in that directory. Like others have said, I would recommend keeping code that used near where it's going to be used, specifically components that are used in views. This might mean you might write the same component in a few places, which drives you to recognize the shared bits and helps you figure out the appropriate abstractions, that leads you to "promote" that explicit, use only once code to the root components directory where the convention is "these components are written in a way where they are intended (and are actually being used) to be used in more than one place. The same could be said for hooks, services, utilities.

[wojciechnowaczyk]

I used similar structure in the last project and it is very cool and clear! I recommend it :)

[dsibinski]

Hi Tania, thanks for sharing that! I especially like storing .js and .test.js files next to each other. I think we often see tests as something separate, while having the test files alongside "production" code would make it more natural to check test files when we want to see how the "production" code works. Likewise, I feel that tests living in a separate folder separate them from "production" code too much 😉

[oceanfox22]

Great article! When I started to develop apps with React, searched for articles like that. If you are like me, you probably understand how valuable such an article, especially for beginnners. The similar approach is recommended by Robin Wieruch and Kent C. Dodds.

Already build couple of mid+ size apps with that structure. Its definitely scalable. By "scalable" I don't mean you can build app with complexity of facebook, but that's enough for most tasks. And of course you should use common sense and adapt the structure when needed.

Also looked into "feature-sliced" - though its presented as "wanna be methodology", actually its just mix of pretentious russian texts and controversial opinionated things. At least, "quick start" is not clear, contains redundant things, using obsolete practices, like using HOCs instead of hooks.

[unordinarity]

Also looked into "feature-sliced" - though its presented as "wanna be methodology", actually its just mix of pretentious russian texts and controversial opinionated things. At least, "quick start" is not clear, contains redundant things, using obsolete practices, like using HOCs instead of hooks. @oceanfox22

Feature-slices is a set of cross-framework practices, it physically cannot force you to use some specific framework apis like hooks, hocs, templates, controllers or whatever you've seen. Please don't try to put our practices in negative way after you don't got them.

[taniarascia]

This is why I waver back and forth about whether or not I should have comments on this blog. This article very clearly states that it is one opinionated way to deal with React architecture, not the only way. I've used it in a large scale production app so I know that it scales very well. I'm very open to hearing new ideas, and building upon what I have and improving upon it or suggesting alternatives.

You could have shown up and said, "Here's another way to handle React architecture that we'd like to share with your audience", and I would have loved that! But instead, you took my article as a personal attack against your system (that I've never heard of), stated that what I've written is non-scalable and trash (it's not), and put 👎 on all my responses asking for clarification on your system. This does not help anyone, and just confuses future readers, and turns this comments section into a carnival.

[RichardOtvos]

I realy liked the article @taniarascia, it's always good to see how other people organize their codebases. I'm a bit confused about some of the comments here, it kind of looks like they haven't actually read the article, just maybe skimmed the filestructure, seen that you have a "components" folder and decided that you must be putting all the components in one folder.

I actually looked at the feature-sliced thing with google translate (so there might be some mistranslations there) and it sounds / looks really close your approach (just with more rude people apparently)

[oceanfox22]

@unordinarity Actually I wrote it about "quick start" section, it can be simplified in favor of more clear project structure instead of focus on obsolete things. I'm not sure why did you name it "methodology", because its not clear what is so outstanding from general approach excluding naming and why did you oppose it to Tania's solution.

Probably should be better if you provide framework-agnostic example, because particularly in React what you abstracted to "features" can be delegated to hooks and you don't need separation like that in context of React library.

https://github.com/downshift-js/downshift You can check downshift library with an example of implementation.

[azinit]

@taniarascia, on behalf of the feature-sliced core-team, I am sorry for what happened in this thread

I should note that the main attacks were from some of our community members, but the core-team itself does not approve of such behavior

Personally, I really just wanted to hint at the weak (in my opinion) points of the proposed architecture

But in general, its worth to note, that the standardization of approaches and sharing of developers' desicions (especially with React) - this is certainly great, and thank you for that!

Anyway, objective discussions can be conducted as soon as we finalize and translate the documentation for our approach.

Our team apologizes, and we hope that the discussion did not spoil too much because of this.

Thanks again for the article!

[oceanfox22]

@martis-git

I should note that the main attacks were from some of our community members, but the core-team itself does not approve of such behavior

Actually just before your previous comment, you was among dislikers, however you removed all of dislikes later.

I'm sorry, if its looking like a try to continue "war", but its hard to imagine, how such an excellent article can trigger such a reaction from random different people of "feature-sliced" community (only from them).

Its highly unlikely that it was not made by purpose.

[azinit]

@oceanfox22

I suggest to close this topic, because your thoughts are starting to go a little somewhere far from reality =)

No offense, just really the discussion on the incident was too long

[oceanfox22]

@martis-git

What do you mean but "far from reality" - is not it true, that you disliked everything around, then mentioned, that it was not you, but "community", who "attacked".

Authors like Tania invest their own personal time to make developers better developers. And its definitely not place to advertise your "feature-sliced".

[chiriaccristian]

thanks @taniarascia for your time!

[rykard95]

I really liked this article because it was well thought out and felt like a walkthrough of a potential architecture one could take when organizing React applications. I'm just starting out and this really helped me focus on what I want to build instead of trying to figure out the absolute best way to organize my code (a sort of hypothesis paralysis). Thanks @taniarascia!

[OlushesiToheeb]

Thanks for this

[Kasuk1]

It would be great if you make a video of this with a standard project. Thanks for the post.

[psiho]

Really nice article. Im far from settled with code organization and love to see how others do it. But I already know i dislike "traditional" approach. My last approach is very similar, but since my app is quite large (crm/offer/invoicing) and main functionalities are quite independant, ai decided to split big parts of the app and then each part is similar to yours. Ialso ise Mobx and not Redux. So i.e. I have CRM/stores, offers/stores, invoices/stores. Same with 'components', etc. Services, util and similar I keep in root as it is used across all parts. I also have _Root folder, again with components, stores, etc., but this one for global App thatglus all together (like main store, ui store, root view, etc.)

[sentinel1909]

Thank you for posting this Tania. I'm a total beginner and need structure. This is such a great jumping off point.

[OpenTechConsult]

Absolutely brilliant!!! This is very clever. Well done.

[AymenMarouani]

Thanks for the article, but how can I configure the aliases when the application is created using create-react-app ? Thanks in advance.

[MadsHaerup]

Hey Tania thanks for the article, I made an npm package to clean up the react boilerplate mess and set up the architecture as you have shown, automatically. Simply use npx pure-react-app :) https://www.npmjs.com/package/pure-react-app

[niemet0502]

Hi Tania, Thanks for this awesome post !! if i understand well the components who are in views folder will connect to the redux store ?

Best regards

[mega94]

lay out the wireframe structure on the github to use as a template.

[ebukaodini]

Hi Tania, Thanks for this awesome post

[skaltenegger]

Very well done and (as you clearly mentioned) opinionated guide. Reading through some of the comments of people suggesting not to "try to put our practices in negative way after you don't got them" (sic!) makes me wanna face-palm and eye-roll as there clearly is no intention to add a constructive comment rather than just trolling. Keep up the good work and high five from NYC 🙌💯

[skaltenegger]

Also, on a more subject-base matter: Finding a structure like this for large scale projects is extremely hard, especially with larger team where everyone has an opinion. There likely is no such thing as "the true ideal way" and every solution/structure comes with its own drawbacks and things evolve constantly. Over the years I have become extremely pragmatic with structuring code bases as, as you pointed out, many decisions are opinionated. Especially when maintaining larger and older code bases, major structural refactors pose huge risk to have implications on production sites so I really see this as a process that takes time and patience and some times dictating of the lead. Again, great article and thanks for sharing your way of structuring @taniarascia ✌️

[aovri]

Thanks so much @taniarascia! Your blog is one of the best resources on Engineering, React and JS I could find. :)

I am wondering if you have seen this post (16K likes): https://alexmngn.medium.com/how-to-better-organize-your-react-applications-2fd3ea1920f1

The author advises moving domain-specific components into the pages or views directory. Do you see any cons in that approach?

Here's my structure:

/pages
    /project
        ProjectPage.js
        ProjectListPage.js
        ProjectSettingsPage.js
        /components <-- is this a good approach? Each domain has a components folder.
            ProjectList.js <-- components related to project only; components here are atomic;
            ProjectSettings.js

For me, the pages are about getting the data and combining components in a specific way. Components, on the other hand, are atomic and focus on a small part of the presentation aspect only (in contrast to pages).

I don't want to mix up the concepts of components and pages and so I keep them in different places inside the /project domain, for example.

I think that your post advises something pretty similar, right?

[aovri]

@taniarascia maybe having a short note in the post on setting up aliases without ejecting the React app would be helpful for people who land on your site and will save them time Googling. :)

https://stackoverflow.com/questions/63067555/how-to-make-an-import-shortcut-alias-in-create-react-app/65746792

[dev-asit96]

Thank you @taniarascia for making it more easy-to-read. I search many of blogs just to get some better idea of react folder structure. It make sense by the way.

[beyond88]

This is very helpful for beginner actually who doesn't know about project structure. I think it is suitable for small/mid-size applications. Thank you @taniarascia for the brilliant article.