5

I am fairly new to Angular.js, and one that confuses me is how to best use modules in an application. It seems to me that modules can contain any of the other common constructs in AngularJS (controllers, directives, filters, services, etc.), but from here I am unsure which module(s) should contain which things.

  • Should I have one module that contains all of the other objects in my application? This seems the easiest to set up, but this smells of the God Object Anti-Pattern to me.

  • Should I divide modules up by types of objects? i.e. one module for controllers, one for directives, etc.?

  • Should I divide them by use? So that all directives, services, and filters that are used for part of the application are together?

  • some other strategy I haven't yet seen / thought of?

Any help would be greatly appreciated.

1

Probably you are not new and have the answer by now. The links from @KeesDijk and @Aaron should provide you a comprehensive answer already.

Since I also had the same question before, this answer could be useful for those who start learning Angularjs.

Should I have one module that contains all of the other objects in my application? This seems the easiest to set up, but this smells of the God Object Anti-Pattern to me.

You have the answer yourself. Unless it is a really small app, having a single module usually not ta good choice.

Should I divide modules up by types of objects? i.e. one module for controllers, one for directives, etc.?

Let's say you have 4 modules for controllers/directives/service/filter each, once you have more than 30 components. Each module have 7-8 components. As you have larger application, you will end up like the previous option.

Also, if you want to reuse one functionality, like user management, you will need to have dependency on several modules.

Should I divide them by use? So that all directives, services, and filters that are used for part of the application are together?

This is the most common recommended practices. One module/folder per one functionality. It is easier to reuse, read (by other programmers), and can scale as the application grows.

Reusability is also better, you can just have a dependency on module 'user'.

some other strategy I haven't yet seen / thought of?

Based on the previous option, you can have variants.

  • It can be useful to structure your module in a nested way by sub-functionality. For example, you can have module 'user' which contains 'user-list' and 'user-edit' modules. (See https://github.com/angular-app/angular-app for example)
  • You can have common/shared module separated out of the rest and prefix them. Ex. 'common', 'common-model-user', 'common-ui-modal', etc.

protected by gnat Jul 1 '15 at 5:22

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.