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.

13m read timeFrom medium.com
Post cover image
Table of contents
1. Clean Folders Hid Scattered Features2. I Started Following Reasons to Change3. State Placement Became an Ownership Decision4. Business Rules Stopped Living in Generic Helpers5. Shared Code Needed More Than Repetition6. Dependency Direction Mattered More Than Directory Names7. The Next Change Became the Architecture TestFolders Describe Files. Ownership Describes the System.
506.5K Impressions5 Comments