Very often I find myself creating directories named "components", "reducers", "routes", ... at the top level of a React/redux app, or "models", "views", "controllers" in an MVC app. Avoid that!.
Try grouping things by what functionality they offer in the app. For example, put the User model, profile view, password reset form and logic, etc... all in a "users" folder. This way, changes are more often confined to a single directory.
I think this could actually be an intuitive idea, but we're often taught a framework or technology, starting from the architectural overview, so that's how we often structure these things in our mind when starting out. Some scaffolding tools even default to building a structure like this.
I would tend to disagree when it comes to components, I think that style of code organization leads to a high amount of repetition, and can make sharing components unintuitive.
For example, you need a simple card component on your user profile so now Card.js lives under /User, but then after some time the same card is to be re-used by another view - now in a large codebase with different devs working on the features in parallel because there is no common place where components exist, it's not totally unlikely that the same UI component is made twice, which doubles future work when the styling needs to be changed.
Even if that worst case scenario doesn't come to pass, in your code you'll end up with import Card from "../../User/Card" or something of that sort, which feels really messy and a bit discombobulating for the dev who's working in that area currently ("Why are we importing a UserCard in our Music view?") or if you decide to lift that component when it gets re-used then you'll end up with a UI component at the top level alongside your journey or feature directories, which feels equally as messy.
Routes and models and things like that are well grouped by domain feature that they represent I guess, but components should probably by and large be feature agnostic, and aren"t a good fit for this organisation technique.
I actually find it's best to use a combination of these. Start by grouping by domain (which may be nested), and then within your domain folders have an opinionated directory structure organized by architecture component. So, for any given domain, the code is organized the same internally, but it's nicely separated from other domains and easy to navigate to.
Bonus points if you use some kind of multiproject structure where each domain's isolation is actually enforced by compilation boundaries, but able to communicate through a shared module's interfaces.
I'm sorry if I'm harping too much on this, but it's been on my mind because it's something that I want to change in my own way of thinking as well.
Organize code by domain, not by architecture component.
Very often I find myself creating directories named "components", "reducers", "routes", ... at the top level of a React/redux app, or "models", "views", "controllers" in an MVC app. Avoid that!.
Try grouping things by what functionality they offer in the app. For example, put the User model, profile view, password reset form and logic, etc... all in a "users" folder. This way, changes are more often confined to a single directory.
I think this could actually be an intuitive idea, but we're often taught a framework or technology, starting from the architectural overview, so that's how we often structure these things in our mind when starting out. Some scaffolding tools even default to building a structure like this.
I would tend to disagree when it comes to components, I think that style of code organization leads to a high amount of repetition, and can make sharing components unintuitive.
For example, you need a simple card component on your user profile so now Card.js lives under /User, but then after some time the same card is to be re-used by another view - now in a large codebase with different devs working on the features in parallel because there is no common place where components exist, it's not totally unlikely that the same UI component is made twice, which doubles future work when the styling needs to be changed.
Even if that worst case scenario doesn't come to pass, in your code you'll end up with import Card from "../../User/Card" or something of that sort, which feels really messy and a bit discombobulating for the dev who's working in that area currently ("Why are we importing a UserCard in our Music view?") or if you decide to lift that component when it gets re-used then you'll end up with a UI component at the top level alongside your journey or feature directories, which feels equally as messy.
Routes and models and things like that are well grouped by domain feature that they represent I guess, but components should probably by and large be feature agnostic, and aren"t a good fit for this organisation technique.
I think it’s perfectly fine to have directories for cross cutting concerns like generic interface elements, logging, network communication, etc.
I actually find it's best to use a combination of these. Start by grouping by domain (which may be nested), and then within your domain folders have an opinionated directory structure organized by architecture component. So, for any given domain, the code is organized the same internally, but it's nicely separated from other domains and easy to navigate to.
Bonus points if you use some kind of multiproject structure where each domain's isolation is actually enforced by compilation boundaries, but able to communicate through a shared module's interfaces.
Completely agree.