A few questions regarding how you organize your code base:
- How do you like to organize your JavaScript, TypeScript, or GraphQL code base?
- Have you written, or know of a post or documentation that details how you like to organize you JavaScript, GraphQL, and/or TypeScript?
Thanks for your thoughts and ideas!
Top comments (5)
There is a silver bullet: modularize as much as possible, split by generic/functional criteria first.
For example, in a frontend framework like Angular you split code by "frequency" (is it created once, a few times, or many times?), then by feature (the pages), then by section of the feature (components), then, at last, by technology (a component is a set of SCSS, HTML and TypeScript files).
Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. Ultimately, the best organization tries to keep related files close together.
I'm not entirely sure what you mean by "Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. "
Like don't put JavaScript tech beside JSON files, or something more like don't put database migrations by the JavaScript or something?
I mean organizing files with the same file type together only because of said common file type is not usually great unless they're related. For example, you put all assets in some /assets folder hence all .jpg are grouped together but they are only because they "make sense" together and they happen to be of the same type. Imagine grouping all css together of different frontend components in the same /style folder: that is an example of bad grouping.
But, in an MVC approach maybe it's a good thing that a /style folder exists in the View part with all the style files, because they make sense together in that case.
Grouping is all about keeping related files close and using functional criteria as much as possible.
A good question you can ask yourself is "are these two files/folders part of the same functionality?"
I wish I could give a quick answer here, but sadly there is no silver bullet I've found.
Most frameworks come with their own advice for structuring things, so if that exists I'll follow that, even if I think its odd.
If a convention doesn't exist, then things tend to break down into two ways which is to create directories by category like views, apis, services, etc. The other is to do it by features so you'd get something like login, dashboard, account, etc.
Beyond that I am a fan of each file does one thing for the most part. Sometimes I'll break that rule if, for example, I have a bunch of small model things I might lump them into one single model file.
The idea though is to make things so that you could guess where they are without a lot of extra help. The bigger and older the code base gets the more important this becomes, but for a lot of smaller projects you can get pretty far with out overthinking it.
Big fan of one thing per file too.
The whole focal point of "make things so that you could guess where they are" I think is a good and noteworthy objective. After all, the code is for us humans eh!