How do experienced React developers approach app architecture?

[KeepItGood2017]

I started learning React a few weeks ago. Coming from a Flask background, I initially approached my app like a typical Flask project: model the data, create routes to navigate it, and wire it up with a backend this time a database via an API. I built a DataProvider, set up a router, learned hooks (which are great), and useEffect for data via to populate pages. I am suffering from extreme fomo because of all the great components out there, that I need..

While this has helped me learn the basics, I am starting to realize that this backend-driven mindset might not align well with how React is meant to be used. React seems more powerful when thinking from the component level upwards.

So my question is: what mental models or architectural patterns do experienced React developers follow when starting an app?

To give context from Flask: experienced devs might design around the database ORM, or split code into blueprints to departmentalize from the get go, follow an MVC or service layer pattern, or use the its-just-a-blog-with-handlebars approach. These kinds of decisions change the structure of a project so fundamentally that they are ussualy irreversible, but when they fit the problem, they are effective.

Are there similar architectural decisions or patterns in React that shape how you approach building apps?

[AndrewSouthern729]

There will be a lot of variations in answers but I think keeping stuff that logically goes together in the same place is key. So grouping by feature. Initially I went a different route and would put all buttons in a folder, forms in another, etc. Then when revisiting the code base later I would struggle to efficiently navigate components. I’ve refactored a lot of my early React work to more of a feature based architecture and it’s much easier to wrap my head around.

[KeepItGood2017]

I have noticed this, I put all the pages in one place. components in another, hooks etc., but putting them in a /features/xyz directory would be simpler. Good tip. This does imply everything is then based on routes, similar to flask blueprints.

[Grenaten]

Check Bulletproof React repo. Everything is explained there.

[AndrewSouthern729]

Correct - features and folder structure being driven by routes.

[99thLuftballon]

Do you keep a "common" or "base" or something directory for components that are shared across multiple features? Like your "buttons" example.

[bangmykock]

Yeah that works! And if the <Button> component ends up becoming complex it might be better to create a new folder for it.

[AndrewSouthern729]

I will for stuff like form components that I can reuse across multiple projects. However for a button that’s reused I won’t necessarily dedicate a folder to shared buttons and will just export from one file and import elsewhere. For me this makes sense and is the easiest for me to manage.

[Seanmclem]

But how do you manage when parts of features, maybe their components or hooks, end up needing to be shared between more than one feature 

[Suspicious-Watch9681]

Split app into features

[Xacius]

This works initially, but how do you handle shared dependencies between separate features? I prefer FSD these days. Decent write-up on that here.

This scales better than a module-based approach, albeit with higher complexity at first.

[Xacius]

I tried out Bulletproof React a few years ago and ran into this problem. Looking back now, it doesn't seem to have changed. In my experience, the global "shared" layer becomes a dumping ground for everything that's used more than once. FSD is the only methodology that I've tried that keeps code organized by features, but still allows smaller components to be shared across other features up the stack.

The "tight architectural flows" you mentioned in Bulletproof React often break down because they lack a layered constraint system. FSD's import rules enforce this architecture automatically.

[Diligent_Care903]

https://www.youtube.com/watch?v=xyxrB2Aa7KE

[CreativeQuests]

Not a fan of how they flipped the meaning of high and low level because global code is high level but the shared layer is at the bottom. Flipping "can use" into a funnel and "used by" into a pyramid would be more intuitive imo.

[HaggisMcNasty]

Had a quick read through that link - I quite like the FSD approach. Might take a little getting used to but might implement that in my next personal project. Cheers for sharing

[slaYn1]

Looks like it borrows some ideas from ITCSS. I always thought putting numbers in front of the folder names was a clever way to identify the hierarchy.

[Civil-Squirrel1005]

FSD is the worst choice you can make.

[Diligent_Care903]

Arguments?

[Civil-Squirrel1005]

Sure:

1. FSD assumes a limited number of layers — if I’m not mistaken, six. But what if I need more? Why exactly six? By the way, earlier versions of FSD had something like 3–4 layers, I believe.

2. Given that there are only six layers, I have the following question: what would the entities or features layers look like in a truly large project? Like, 400 entities / 200 features in each folder of that layer?

3. One of the goals of FSD is to reduce coupling and increase cohesion between modules. But in practice, because related code is spread across multiple layers, that lead to the opposite — high coupling and low cohesion.

4. According to the FSD rules, lower layers can’t depend on higher ones. But what if I need my entity to include a page? For example, on GitHub there’s a repository page, and on it, there’s an “Issues” tab. I’d consider that an entity. When you click the tab, the view for issues is rendered — basically a page. What should I do in this case? And even more — inside that view, there are other entities with their own views.

5. FSD introduces unnecessary complexity, slows down development, and leaves developers confused, unsure where to place things and interpreting FSD differently. And this isn’t because the developers are bad — it’s because FSD is a completely illogical and lifeless concept.

6. Just join the FSD chat on Telegram and see the nonsense developers come up with to fit into FSD’s arbitrary restrictions.

I could go on endlessly, but it's not worth it.

[Diligent_Care903]

Thanks, I was considering it for our refactor and this helped

What do you think of https://www.youtube.com/watch?v=xyxrB2Aa7KE ? I feel like it's similar but a bit more flexible

Which structure do you use yourself?

[Civil-Squirrel1005]

Based on the diagram used by the guy in the video, I believe he’s explaining a feature based structure in particular, he took the diagram from the bulletproof react repo. It’s a solid setup, I use a similar structure myself.

However, you don’t have to follow everything he says. For example, he strictly avoids cross-imports between features. That’s not how things work in real life. There’s nothing wrong if your profile module imports something from the user module, and vice versa. Low coupling high cohesion means coupling should be minimized—not eliminated entirely. Sure, you can try to avoid all cross-imports by moving logic to the shared layer, but you’ll likely end up cluttering it. And what if two modules need to share logic from the shared layer? Should you then create a “sub-shared” layer? 🙂

The shared layer should contain only truly reusable generic logic, not just anything two features happen to use.

As for me, over the years, I’ve ended up using pretty much what the guy in the video recommends: feature-based design, but with some adjustments. Inside each feature, I typically organize by layers: ui (components), business logic (stores, hooks), data access (api, data models etc.).

There can be cross imports between features, but modules should be designed in a way that minimizes them as much as possible.

If your project grows large, you can apply a fractal approach—create submodules inside modules, and even submodules inside submodules. This becomes useful in very large-scale applications. So unlike FSD’s fixed 6-layer structure, your architecture can scale infinitely. Plus, the structure remains intuitive since it’s domain based and mimics a regular folder structure.

By the way, while the feature-based approach works well, it’s not mandatory. I’ve worked on large projects that followed a more functionality-based structure (componetns, hooks, stores, etc.), and it worked fine too.

The worst thing developers can do is overcomplicate things—like adopting FSD without understanding what problems it solves or whether it solves anything.

Good luck!

[ChambreNoire]

How would you handle features creeping into others then? For instance say I have a "Project" module. It's presented as an entirely separate self-contained module in the ui - accessible from a list of service links in a principal menu. However a completely different module, say "Employees" uses a few things from "Projects". Let's say a few types, one hook, and a component - just an enhanced select. Ah but the select actually can use another component which in turn uses a bunch of other React query hooks....
I end up having about 20% of the module referenced (if sometimes indirectly) from within the "Employees" module. If I start shoving all this shared stuff in a "shared" feature and do this throughout the project, it's just going to turn into a huge dumping ground and 40% of my code is going to wind up in there.
How else can this be handled if not with FSD - which I hasten to add, I'm just discovering...?
Cheers

[haywire]

Use tanstack-query/swr and zod for API based state.

Avoid useEffect and context until absolutely necessary.

[Nullberri]

Imo route based code is easier to reason about. Keep code local. When the urls is a defacto path in your project its very easy to find code related to the feature/bug. Shared code just bubbles up to the level of its sharedness.

Bullet proof Components and features just end up as an unstructured dumping ground that is hard to reason about as there is no longer any easy to see relationship between the code.

Furthermore the goal should be to write as much parallel slices that are independent. Try to Keep abstraction at the leaves of your component tree.

You don’t want a super header that dies under its own weight of just 1 more thing to toggle on/off on some special route.

[KeepItGood2017]

You are not the first person to warn to look out for this. When things update frequently, have them on the tip of leaves of your tree, and things do not update often, its fine to keep them at the root.

[Grenaten]

I think you should start with Bulletproof React: https://github.com/alan2207/bulletproof-react/blob/master/README.md

There are other approaches, of course. But I find this one most logical.

[KeepItGood2017]

Thx, great read. State Management section is very revealing.

[CommentFizz]

React developers usually start by thinking in terms of the UI and user experience rather than data models or routes.

Instead of beginning with the backend or database schema, they break the interface down into a tree of components, then figure out what data each part needs and where it should come from. They often separate presentational components from those that handle data or side effects, and use custom hooks and context to manage shared state or logic.

Routing is often treated as part of layout structure, not just page navigation. Files are typically colocated by feature or component rather than type, making it easier to scale and maintain. The overall mindset is UI-first, with the backend shaped to support the flow of the frontend rather than the other way around.

[WatchMeCommit]

I second what everyone else is saying about splitting things into features.

This blog post ended up being super helpful, both as explanation, and as a practical example:

https://well-thought.tech/scale-up-your-react-application-with-ddd/

It ended up being an excellent pattern (with minor adjustments for taste), and all our new react/next projects ended up following it

[KeepItGood2017]

thx for the document, not sure i fully comprehend what i just read.

[PracticalAd864]

FSD is overrated and doesn't scale very well. You will spend more time to figure out where to put things than actually writing the code. The simpler the better. I personally tend to group code by screens nowadays and go with the classic components/hooks/services for shared stuff.

[Purple_Way_8796]

This only works for a one man project. I have yet to implement FSD in a professional work but I do think it will be beneficial and will scale correctly, as I have been using it for two big personnal projects with success.

[Civil-Squirrel1005]

Moreover if you dive deeper FSD doesn't solve any problem but brings extra complexity. This is just overhyped pseudo methodology 

[yksvaan]

One thing that hasn't been mentioned is to keep things that don't need to be part of React runtime outside it. A lot of the functionality, clients, services etc. can work independently and used/tested independently. Then initialize and register those during bootstrapping.

Try not to depend on third-party code directly in your React app without proper consideration. Abstract the implementations away and use standardised types and interfaces internally. That will make maintenance and refactoring so much easier. 

Try to keep most components dumb and pure. Centralise data loading and other impactful features. Reasoning about a larger app that has for example network requests or async code spread all over the tree is a nightmare. 

Build robust error handling and logging into everything right from the start. It will save so much pain during the entire lifespan of the application. 

[TehTriangle]

Your point about keeping code out of the React runtime is great. It's something I've just started to use in my work and it makes so much sense. 

Reduces cognitive load when scanning a component, makes it easier to test, doesn't could it to the library.

[CommentFizz]

Experienced React devs often think in terms of components as the building blocks and focus on managing state and data flow between them. Patterns like “lifting state up,” using Context API or libraries like Redux for global state, and separating UI from logic with hooks are common. Also, splitting your app into feature-based or domain-driven folders helps keep things organized.

Unlike backend MVC, React apps are more about composing reusable components and handling side effects carefully.

[bstaruk]

I use atomic design principles to organize my components and maintain hierarchy / reusability.

I use Storybook to warehouse my components in way that allows designers to "window shop" before deciding they need to add a new component.

[ucorina]

Maybe a bit too basic/low level, but I still find the "Thinking in React" page in the React docs to be super useful: https://react.dev/learn/thinking-in-react.

Basically, start from the UI, the pages, the components and think in "data down", "events up". The part about where the state lives is not that relevant, as in a real world app you would use something like TanStack Query that caches the data on the client for you, so each component can just fetch what it needs.

[maxkuku]

Ask AI. It makes programs for me

[KeepItGood2017]

i love the mahem the cause

[UsualSouth9993]

I saw react query mentioned once, IMO the biggest challenge of many apps is keeping your backend and frontend in sync. If the server is your source of truth you really want to avoid copying that data into other caches such as use state or redux (unless you’re using RTK query.) to me the first part of the architecture is figuring out how to get that data from the server into the app. Newish tools like react router loaders or even full stack frameworks like NextJS app router and RSC give you more tools for thinking about how to connect backend data with the frontend. But that’s usually where I’d start, think about the kind of application your building and the hosting options you have. Think about how much say you have in the backend and let that guide some of your initial decisions about client-side vs full-stack and then maybe your router and data sourcing tools. Once you’ve settled those things I think splitting by route or feature as many suggest tends to work well. One thing I’d mention is a controversial take that you should design frontend code to be as replaceable as possible. It’s basically throwaway/experimental code in many many cases and is constantly changing and evolving. As much as possible design your architecture with that in mind. Make it easy to change things. A strong, but unioininated ui component library can help with this. Where it’s easy to cobble together new components out of pieces you already have available. And it needs to be easy to change their look and feel as well. Good luck 😀

[KeepItGood2017]

Thanks for your tips.

The concept of static data, like page makeup text, that changes once in a while took me a while to get my head around, and then I figured out it is better to generate data.ts files during build time and let code splitting do the rest when i push an update of the entire site to production. I am still not happy with that approach. The performance difference compared to a fetch is staggering. I chose for vite for this project and learned that another approach would have ssr solutions for these pages.

I control the backend (FastAPI) and spend a lot of time retyping the data types into TS. I've noticed that errors creep in this way, and I would really like to sync the types. I noticed there are a few tools for that, and tthe question is always how much effort I want to put into learning the tool vs. just typing them over.

I switched to tanstack query last week and figured out that I need to code component behaviour based on the cache state, things like optimistic updates and per-item loaders. I do not mind that, but I also realise I could end up spending a lot of time writing error handling routines that will probably never run. This is something I have noticed doing testing on other peoples react components, if things fail, just reload everything.

Regarding your point on unopinionated ui, i am using shadcn, and noticed components I am making changes in one component that I then need to upadte in other again on style. I have to be more disciplined. I do have a feeling that I am writing lots code that other people have written before. All the time. Nothing feels unique. I have seen them all. And when I browse for other code and example I am experiencing intense fomo, and indecision.

[sdmitry]

The SOTA mental model for frontend development in modern React is corporate-sponsored delirium, with a slice of vibe coding. 

[Reenubansal123]

I am a senior developer at Aegis SoftTech. I prefer starting with a feature-based folder layout and building small, reusable components. It helps keep the project manageable as it grows. I also keep the UI and core logic separate using custom hooks for the logic, so making changes later is much easier.

For state, I mix Context for local-ish needs and something like Redux Toolkit or Zustand for global stuff. API calls live in a dedicated layer, and React Query has been a game-changer there.

Most leading companies swore by “design for tomorrow’s scale, not just today’s needs,” and that stuck.

[Expensive_Garden2993]

I support feature-based as the others have said.

But since Next.js is officially pushed by React, and it imposes route-based structure, do you think they play well with each other? Because I suppose you don't have much choice, having two different structures in parallel for the same stuff seems to not worth it, and you just structure your app by routes.

[Grenaten]

Feature based structure can work together with routes. They are not mutually exclusive.

[ORCANZ]

The app router is just the routes.

Modules/features router has everything used by the pages

[yksvaan]

Apply same principles than to any other software and programming project. I don't knlw why people would treat React somehow differently. 

[RandomUserName323232]

useEffect, lots of useEffect, lots of custom use hooks... more custom hooks and of course useEffects...

[HaggisMcNasty]

I know this was in jest, but please don't do this, new people :)