Hacker News Reader

Comment by davidwparker | Hacker News Reader

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?

View on HN

Can you give an example of how you've organised the modules? Like one per model (a products module) or by section of the site?

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

I don't understand what you would have in "models". Services?

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

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

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

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

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

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

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

Why not both?

Reply on news.ycombinator.com