5 ms·
Working with a large Angular app, I've found it much nicer to split away from the "Rails"-style convention of grouping by type (controllers, models, etc) and in
by davidwparker 13y ago
Working with a large Angular app, I've found it much nicer to split away from the "Rails"-style convention of grouping by type (controllers, models, etc) and instead grouping by modules. This plays especially well with Angular where you can group everything within a module together and include a single module which ties all the dependencies together.
Curious if others do something similar and group code together by modules or does everyone group by type?
- t0mas88 13y agoFor front-end such as Angular I always group in modules, usually nested modules for larger apps. For back-end systems sometimes type makes more sense, especially when the app grows quite big and uses a layered architecture.
- ganarajpr 13y agoI do the same as you. Group by Module - which in my humble opinion is the real intention of the modules. Oh between I do group by Type inside of a module.
- glazskunrukitis 13y agoWhy not both?
- p3rs3us 13y agoI recently spent days writing AngularJS app and I came to same conclusion that I should have split the app into modules. Even though the style of grouping together Controllers and Services works well, it still won't be easy to maintain when the size of app grows big.
- Rodeoclash 13y agoCan you give an example of how you've organised the modules? Like one per model (a products module) or by section of the site?
- rs 13y agoIf I'm not mistaken, instead of splitting into: controllers/ users.js teams.js models/ user.js team.js Just have: modules/ users.js teams.js Where model and controllers for each function is defined within a single file. I've switched to this convention as well - less context switching of files.
- Kiro 13y agoI don't understand what you would have in "models". Services?
- babby 13y agoI'm always excited to structure my projects in a different more effective way - well, it's more of a struggle - anyway, this sounds interesting. Can someone elaborate on the file structure and structure of files and the way they connect? I'm rolling with a MVP structure that frankly is becoming cumbersome with my current project's size.
- tegeek 13y agoWhat I've done myself and found it pretty scalable is as follows: appShell/ views/allbaseviewshere viewmodels/controllers or viewmodels for the core views services/baseservices moduels/ account /views/ /viewmodels/ /services/ order /views/ /viewmodels/ /services/ /controllers/ static /css/ /js/ /images/ AppShell contains the app starter page, controllers and util services (showing popups, utility functions etc.) AppShell/Views contains all the UI Skelton for the app (bootstrap main page, etc) Every folder inside "modules" contains views, controllers (viewmodels) and services belongs to only that module. Account folder contains views for user registeration, sign in, change user profile, etc. etc. This way you can keep building new moduels in their respective folders without touching the frozen code (already built modules). Each module talk to outside world using "services". No module can touch anything belongs to other modules but with "services".
- joevandyk 13y agoI like grouping by functionality. All the account-related code in one directory, all the order-related code in another, etc. Bugs me to have the order logic spread out in the views, models, controllers, hepers, libs, etc folders.
- mac1175 13y agoI do it the way you just mentioned. I create specific modules and have them inject their dependencies. Each modules I create has its one or more models within its domain. I was going to go the repository route (one module per type) but it seemed overkill.