33

I'm totally newbie at using AngularJs and although I've been through the tutorials, I still have loads of unanswered questions in my mind. My main concern right now is how should I divide my application into modules ?

Basically I need to build an app which will act as a portal to various apps, each representing a business functionality (sometimes with little to no relationship with each others).

In the tutorial, they show how to create one app with multiple views. What I need, is one app with multiple modules, each module having its own views (and I'll probably have shared views too).

Has anyone worked on an app with that kind of structure ? Could you share your experience and how you've organised things ?

The AngularJS Seed project (https://github.com/angular/angular-seed) is good but it does not really show how to build a complex application.

4
  • you dont need to create one big app if you have multiple apps that are not related , just create one app per business. An app can reuse other apps services , controllers and directive. Remember that a "web app" is still a web page, no matter what ,it is not like a desktop software. Commented Apr 11, 2013 at 9:11
  • 1
    I may have express myself incorrectly. I only have one app, but it's BIG. And I want to split it in various business modules. Each business module would contain its own set of views, directives, controllers, etc... But in the end, it's the same web application, with just one entry point. Is it a good approach, and how should I organize my code ? Commented Apr 11, 2013 at 9:19
  • doesnt matter , it is up to you to split the files as you wish. Some people use 1 file per service , controller or directive , some people split it per 'feature' , doesnt really matter because of dependency injection. you can re-open a module accross multiple files , etc ... really it is a matter of taste. You just need all your js files in your html at the end. I personally have 1 file per type ( 1 file for services , 1 for directives , 1 for controllers ) even for large apps. Commented Apr 11, 2013 at 9:25
  • 4
    1 file per type, really ? How many lines of code do you have in each of these files ? For a big app, it must be enormous. Thanks for sharing your experience. Commented Apr 11, 2013 at 11:34

5 Answers 5

31

[EDIT] I wrote an article on my blog to explain things in more details:

read it on sam-dev.net and you can now read part II, with code sample.

I'll answer my own question. Not because I think it's the best approach, but just because it's the one I've decided to go with.

This is how I've divided my business modules into folders

  • app
    • businessModule
      • controllers
        • index.js
        • firstCtrl.js
        • secondCtrl.js
      • directives
      • services
      • views
      • filters
    • anotherBusinessModule
    • shared
    • app.js
    • index.html

Each module has its own folder structure for controllers, directives, etc...

Each folder has an index.js file and then other files to separates each controller, each directive, etc...

The index.js file contains the definition of the module. For instance for the controllers of the businessModule above:

angular.module('myCompany.businessModule.controllers', []);

There's no dependencies here, but there could be any.

Then in firstCtrl.js, I can reuse that module and add the controller to it:

angular.module('myCompany.businessModule.controllers').controller('firstCtrl',     

        function(){
});

Then the app.js aggregates all the module that I want for my application by adding them to the dependencies array.

 angular.module('myApp', ['myCompany.businessModule', 'myCompany.anotherBusinessModule']);

The shared folder contains directives and other things that are not specific to a business module and that can be reused anywhere.

Again, I don't know if it's the best approach, but it definitely works for me. Maybe it can inspire other people.

EDIT

As the index.js files contain modules declarations, they must be referenced in the html page before any other application scripts. To do so, I've used the IBundleOrderer of ASP.NET MVC 4:

 var bundle = new ScriptBundle("~/bundles/app") { Orderer = new AsIsBundleOrderer() };
 bundles.Add(bundle.IncludeDirectory("~/app", "*.js", true));

public class AsIsBundleOrderer : IBundleOrderer
{
    public IEnumerable<FileInfo> OrderFiles(BundleContext context, IEnumerable<FileInfo> files)
    {
        files = files.OrderBy(x => x.Name == "index.js" ? 0 : 1);
        return files;
    }
}
Sign up to request clarification or add additional context in comments.

4 Comments

Interesting ...could you please show me how you have arranged the "script" tags?
see EDIT in my post. You must insert the index.js scripts before the other application scripts.
How do you inject a module service into an app controller? I've been trying something similar and modified my code to follow your approach, but I'm getting the dreaded "unknown provider: xProvider" error when I try to inject the "myModule.x" service into my controller.
either you need to use the square brackets with a list of named dependencies. Or if you use a variable to store your service, just use $inject to specify dependencies. In both cases, this is to make sure your code does not break once you minify your scripts. If the error happens before minfying the scripts, then you have another problem, but we will need to see your code.
11

Sam's method seems to be the way to go in most cases. The current Angular documentation has it setup as a module for each controller, service, etc, but this has been contradicted by Miško himself from google.

In a recent Angularjs Best Practices video by Miško, he shows how the structure of modules could be laid out for ease of testing as well as easy scaling. Keep in mind how you structure the modules is not supposed to affect performance within an angular app.

From developing angular apps, I would suggest using the best practices method for the aforementioned reasons. You may wish to make your own node script to generate your controllers, etc for the time being which could include say the module you wish to create the controller in and the name, which would then auto generate your controller and proper test spec creation.

If you want a great read on the setup there is an excellent post here regarding setting up the project based on where you think it will be heading.

2 Comments

That AngularJS Best Practices vid is GOLD.
Very short answer from the video: divide modules by FEATURE. Keep in mind that a certain module (aka feature) can depend on multiple controllers, services, etc, so it make sense to keep all of those in the same module. That way, if you need some feature from another part of the application, just get a reference for the corresponding module and you are good to go.
3

you should go to the yeoman https://github.com/yeoman/yeoman and yeoman generator structure: https://github.com/yeoman/generator-angular, it becomes a better solution to setup application than angular-seed. For different business modules, you should create different app and share services and directives

2 Comments

Well, from the yeoman website: 'This beta does not yet work on Windows. We'll be working hard to fix this towards the final release.' I can't use it then :)
Yeoman generator gives you a "by file type" structure, which is suitable for small apps but not really great when your app grows IMO.
2

For those who are interested, I made a "modularized" version of Angular Seed that fits better with Misko's best practices: https://github.com/sanfordredlich/angular-brunch-seed-modularized

It's set up with Brunch so you very quickly get page reloading, test running and much more. You can be developing quickly and if you follow the patterns in the code, your application should scale reasonably well. Enjoy!

Comments

1

The draw back I have found to the approach the yeoman generator takes is that it doesn't really lineup with the angular modules so it doesn't feel very cohesive to me. So as the project gets larger and you are working on a particular component I found myself flipping around a lot in the source tree.

I have recently come across a different approach here. This approach groups the files by angular modules and feels more cohesive to me. One possible drawback to this is the fact you are required to build the site you can't just run it in place. The grunt watch task in that project helps with this though.

1 Comment

This is now the recommended "go to" structure for most angular apps.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.