<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn" -->

---
title: How I Learned to Structure React Projects Around Change,...
description: Technical folder structures (components, hooks, services, utils) make React repos easy to browse but hard to change, because a single feature&#x27;s logic is...
canonical: https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: How I Learned to Structure React Projects Around Change, Not Folders | daily.dev
og:description: Technical folder structures (components, hooks, services, utils) make React repos easy to browse but hard to change, because a single feature&#x27;s logic is...
og:url: https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn
og:image: https://api.daily.dev/og/posts/CCelAqKhN.png
og:image:alt: How I Learned to Structure React Projects Around Change, Not Folders
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# How I Learned to Structure React Projects Around Change, Not Folders

**[Medium](https://daily.dev/sources/medium_js)** · 13 min read · 120 upvotes · 5 comments

## Summary

Technical folder structures (components, hooks, services, utils) make React repos easy to browse but hard to change, because a single feature's logic is scattered across unrelated directories. The key insight is organizing code around ownership of change rather than file type. This means colocating a feature's components, state, validation, API calls, and business rules under one feature directory. State placement should reflect lifecycle and source of truth, not convenience. Business rules belong near the feature that owns them, not in generic utils. Shared code should only be extracted when callers truly share the same meaning and change together. Finally, dependency direction matters: features should depend on stable shared primitives, not each other's internals. The real test of an architecture is how confidently a developer can locate the owner of the next change.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://medium.com/skillstuff/how-i-learned-to-structure-react-projects-around-change-not-folders-8f680a3556e9>

## Community discussion

Top comments from developers on daily.dev.

**@eugenevazhnizky** · 6 upvotes

> So essentially a [Vertical Codebase](https://tkdodo.eu/blog/the-vertical-codebase)

**@nthadam** · 2 upvotes

> I like this approach and eagerly support it, but one enormous caveat: reality is harder to maintain. Teams have devs rotating in-and-out. Businesses pause feature dev for weeks or months depending on indecisive leadership. Maintenance disciplines atrophy due to fatigue and apathy. I'm all for striving for an ideal, but I recognize the bitter reality isn't kind to our shiny goals. Tough to balance. Good concepts

**@allinonetools** · 1 upvotes

> Feature-first architecture has been one of those small changes that keeps paying off as a project grows. Less hunting, more building.

**@kartiknvj** · 1 upvotes

> Organizing around what changes together instead of by file type is the shift that survives a codebase growing past a few contributors. Colocating a feature's logic, state, and UI means one change touches one folder instead of five. I moved to this and PR diffs got dramatically easier to review. How do you handle the genuinely shared primitives that don't belong to any one feature?

**@kkurko** · 0 upvotes

> I use Feature-Sliced Design: it has clear and straightforward rules, it scales great and it can be applied to any fronted technology (React, Angular, Vue and so on).
>
>
> There is definitely a learning curve and it might be an overkill if your codebase will stay super small (in this case layers are perfectly fine), but overall it’s really good and I highly recommend at least learning about this approach
>
>
> [https://feature-sliced.design/](https://feature-sliced.design/)

## Similar posts on daily.dev

- [React Folder Structure for Beginners: The Folder Organization That Finally Made Sense to Me](https://daily.dev/posts/react-folder-structure-for-beginners-the-folder-organization-that-finally-made-sense-to-me-uvkbilaco) · Medium · 275 upvotes · 22 comments
- [Designers already think in React](https://daily.dev/posts/designers-already-think-in-react-rbce4lfse) · thoughbot · 5 upvotes · 1 comments

---

Tags: [#react](https://daily.dev/tags/react), [#architecture](https://daily.dev/tags/architecture), [#frontend](https://daily.dev/tags/frontend)

[View this post on daily.dev](https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"How I Learned to Structure React Projects Around Change, Not Folders","url":"https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn"},"datePublished":"2026-07-22T17:53:36.259Z","dateModified":"2026-07-22T20:18:30.103Z","description":"Technical folder structures (components, hooks, services, utils) make React repos easy to browse but hard to change, because a single feature's logic is...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9091d966c43a5366e9e8ccf030de2cb8?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/9091d966c43a5366e9e8ccf030de2cb8?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":5,"discussionUrl":"https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":120},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":5}],"keywords":"react,architecture,frontend","timeRequired":"PT13M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"How I Learned to Structure React Projects Around Change, Not Folders"}]}
{"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/how-i-learned-to-structure-react-projects-around-change-not-folders-ccelaqkhn","comment":[{"@type":"Comment","text":"So essentially a Vertical Codebase","datePublished":"2026-07-23T08:49:08.002Z","url":"https://daily.dev/posts/CCelAqKhN#c-e9WUCaGVj","author":{"@type":"Person","name":"Eugene Vazhnizky","url":"https://daily.dev/eugenevazhnizky","image":"https://avatars.githubusercontent.com/u/28874355?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}},{"@type":"Comment","text":"I like this approach and eagerly support it, but one enormous caveat: reality is harder to maintain. Teams have devs rotating in-and-out. Businesses pause feature dev for weeks or months depending on indecisive leadership. Maintenance disciplines atrophy due to fatigue and apathy. I’m all for striving for an ideal, but I recognize the bitter reality isn’t kind to our shiny goals. Tough to balance. Good concepts","datePublished":"2026-07-23T12:25:52.736Z","url":"https://daily.dev/posts/CCelAqKhN#c-PXxtNFqvO","author":{"@type":"Person","name":"Adam Leis","url":"https://daily.dev/nthadam","image":"https://lh3.googleusercontent.com/a/ACg8ocKmBiFBNwyPmFKXkvqjKLyqClpM8dijiZl9zCT2dhJeMoZfxbUs=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"Feature-first architecture has been one of those small changes that keeps paying off as a project grows. Less hunting, more building.","datePublished":"2026-07-24T02:50:51.572Z","url":"https://daily.dev/posts/CCelAqKhN#c-8cBNNCBnd","author":{"@type":"Person","name":"AllInOneTools","url":"https://daily.dev/allinonetools","image":"https://media.daily.dev/image/upload/s--4ZT8QlF0--/f_auto/v1769790028/avatars/avatar_igzBsWloJeaegzm9bQltZ?_a=BAMAMiiu0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"Organizing around what changes together instead of by file type is the shift that survives a codebase growing past a few contributors. Colocating a feature’s logic, state, and UI means one change touches one folder instead of five. I moved to this and PR diffs got dramatically easier to review. How do you handle the genuinely shared primitives that don’t belong to any one feature?","datePublished":"2026-07-23T14:18:59.195Z","url":"https://daily.dev/posts/CCelAqKhN#c-THvr8hJLB","author":{"@type":"Person","name":"kartik-nvjk","url":"https://daily.dev/kartiknvj","image":"https://media.daily.dev/image/upload/s--3gGgsVCw--/f_auto/v1781456774/avatars/avatar_TvTVeiMdkRCqWUDullFmy?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"I use Feature-Sliced Design: it has clear and straightforward rules, it scales great and it can be applied to any fronted technology (React, Angular, Vue and so on).\nThere is definitely a learning curve and it might be an overkill if your codebase will stay super small (in this case layers are perfectly fine), but overall it’s really good and I highly recommend at least learning about this approach\nhttps://feature-sliced.design/","datePublished":"2026-07-30T17:45:12.793Z","url":"https://daily.dev/posts/CCelAqKhN#c-O1hythdN2","author":{"@type":"Person","name":"Kirill Kurko","url":"https://daily.dev/kkurko","image":"https://avatars.githubusercontent.com/u/58859242?v=4"}}]}
```

