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 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.