The folder structured shared is broken for the simple fact that artifacts are categorised by programming type rather than usage. As an example all models are grouped together broken away from the services that may be using them. This means the relationship between a collaborating system are never colocated.
I fail to see the value of grouping all models together, maybe its me but i would rather that collaborators are co-located. I cant see any value to have all models.
Naturally, there’s some code to glue it all together and some shared services, and it’s still a mess sometimes, but overall when related things stay close to each other it’s easier to comprehend.
Maybe its me, but wouldnt the auth feature only have 1 or 2 models at most ? Same question for API and components, pretty sure you could put them in the parent directory and the names of each shoudl make their core responsibility obvious.
> wouldnt the auth feature only have 1 or 2 models at most
Probably! (Sessions, OIDC connections, probably users if small enough.)
I don’t think putting it all together into the root directory is the way to go. The idea is to store everything related to one particular feature together, so that all the relevant code stays in one place:
// features/auth/models.ts
class User { ... }
// features/auth/api.remote.ts
import { User } from "./models";
export const authorizeUserForm = form((username, password) => { // [1]
// ...
});
// features/auth/components/SignInDialog.tsx
import { authorizeUser } from "../api.remote";
export default () => <form {...authorizeUserForm}>
...
</form>;
Neither of these are good examples of organization. You should organize stuff by feature (without having any folders called "feature", "shared", "core" or "utils"). Essentially the rule for organization is simple; the moment you have any folder that is a catch all you have lost.
Another reason why tags are better than folders. If your team can't decide between different systems just use all of them. Then you can group by feature, layer, role, author or anything else you need right now.
The problem is no existing file system supports this so you can only use it to organize notes or issues not your code.
The folder structured shared is broken for the simple fact that artifacts are categorised by programming type rather than usage. As an example all models are grouped together broken away from the services that may be using them. This means the relationship between a collaborating system are never colocated.
I fail to see the value of grouping all models together, maybe its me but i would rather that collaborators are co-located. I cant see any value to have all models.
Agreed. I’m trying to group files roughly by “feature”:
Naturally, there’s some code to glue it all together and some shared services, and it’s still a mess sometimes, but overall when related things stay close to each other it’s easier to comprehend.Maybe its me, but wouldnt the auth feature only have 1 or 2 models at most ? Same question for API and components, pretty sure you could put them in the parent directory and the names of each shoudl make their core responsibility obvious.
> wouldnt the auth feature only have 1 or 2 models at most
Probably! (Sessions, OIDC connections, probably users if small enough.)
I don’t think putting it all together into the root directory is the way to go. The idea is to store everything related to one particular feature together, so that all the relevant code stays in one place:
[1]: some RPC magic here, like https://svelte.dev/docs/kit/remote-functionsNeither of these are good examples of organization. You should organize stuff by feature (without having any folders called "feature", "shared", "core" or "utils"). Essentially the rule for organization is simple; the moment you have any folder that is a catch all you have lost.
Another reason why tags are better than folders. If your team can't decide between different systems just use all of them. Then you can group by feature, layer, role, author or anything else you need right now.
The problem is no existing file system supports this so you can only use it to organize notes or issues not your code.
> The problem is no existing file system supports this
Use sym- and hardlinks?