CODEWITHSUNDEEP
templatesarchitectureprojectangularjs
dariofarzati
dariofarzati

Reputation: 8648

Recommended scalable AngularJS project structure?

I have seen several AngularJS project templates: the seed project at the official website, Yeoman's generated, and AngularFun.

Are there any other (un)opinionated templates I should take a look at, or any related pattern you would suggest for a scalable AngularJS project?

By scalable I mean

Upvotes: 46

Views: 40538

Answers (6)

Kenneth Lynne
Kenneth Lynne

Reputation: 15579

Warning: Shameless plug.

You should definitely check out generator-angular-xl.

It aims especially at creating large scale AngularJS applications by grouping code logically, scaffolding unit tests, and automatically injecting your js and css files into index.html etc. It also helps out by creating a mock back-end for your data, effectively making it a good choice when developing prototypes that also can live into becoming full blown applications. It does NOT generate any back-end code, so you are free to choose whatever back-end technology you want.

Upvotes: 1

Pete BD
Pete BD

Reputation: 10161

You can take a look at a demo application that Pawel Kozlowski and I are putting together: https://github.com/angular-app/angular-app.

It doesn't provide any support for loading files on demand but you can see we spit modules up into separate files and set up testing as a first class component. We have a build process (using Grunt) that concatenates (and minifies on release) the js files and can run unit and end to end tests.

We have chosen to split our modules into two groups functional application areas and common cross cutting library code, rather than a simple split into directives, filter, services and so on. In side a functional area we might have some service, directives, controllers and templates.

This makes developing against a functional area easier as all the relevant items are in one place.

The project relies on a simple nodeJS server to deliver the files (supporting HTML5 mode deep linking) and also to provide authentication and authorization services.

Upvotes: 30

user1234511
user1234511

Reputation:

This project sounds promising http://vesparny.github.io/ng-kickstart

It makes you able to split your codebase by feature and keep your code reusable, as well as livereloading thanks to a custom Grunt task for that.

The project is also unit testing oriented and comes with a custom "dist task" that let you to create an optimized, production ready release.

Upvotes: 1

ottsch
ottsch

Reputation: 431

You should try ng-boilerplate. The most promising kickstart template for bigger AngularJS projects: http://joshdmiller.github.io/ng-boilerplate/#/home

Upvotes: 8

James Strachan
James Strachan

Reputation: 9198

I agree with the points other folks have said so far; its very easy to split things up into separate modules and have the modules depend on each other with regular AngularJS stuff. Then your JS code can be split into whatever files and directory trees you prefer.

Just thought I'd mention what we're doing in the open source hawtio project which is based on AngularJS. We've taken modularity to a bit of an extreme :) hawtio uses plugins which can be discovered at runtime in the running server (e.g. deploy and undeploy UI functions at runtime). So based on some REST query or JMX detection we can dynamically and or remove plugins.

e.g. here are all our current default plugins

In terms of layout, each plugin has its own directories for code (js), html partials (html) and anything else (e.g. css / img directories) which makes it easy to keep things nice and modular. e.g. here's the camel plugin which has its own html, js and img folders.

Then a specific plugin defines its own AngularJS module, directives, filters and which can then depend on other modules.

We've not come up with terribly many helpful naming conventions for the source files so far though :). We find writing a file per controller seems simplest; but other than the fooPlugin.ts file and the helpers.ts file (for general module specific helper functions) we've not yet found any other meaningful naming conventions so far.

Upvotes: 4

matys84pl
matys84pl

Reputation: 8334

I would say that all of your points can be easly achived, at least without any modifications to Angular.

  • being able to split controllers, directives, filters, etc. in their own files;

this can be of course done with basic Angular, as you can include as many script tags with controllers/services as you want. Of course it's not scalable at all, so the best option would be using AMD modules, like RequireJS. This is one of the seeds that have this kind of configuration: https://github.com/elsom25/angular-requirejs-html5boilerplate-seed

  • being able to load these files on demand rather than making the browser load everything;

As pkozlowski suggested in the comments, there is already and entry with some description of the problem, you will see that I was also working to solve this, and actually had some results. I have a working example of loading controllers, templates and directives on demand using RequireJS and the resolve param of route configuration.

  • being able to have common, cross-project components (e.g. common directives, filters or services)

Having the previous points resolved it could be easily achived using RequireJs modules.

I've been wondering whether starting an agularjs-lazy-seed project would be a good idea? Is there any demand for that? We could even take it further and move the routes configurations outside the usual configuration, let's say you have a views.json file (ideally a service that responds with json) with the views you want to include in your application:

{
    "views" : {
        ....
        "account" : {             
             "path" : "/account" // route path
             "name" : "Account", // view name
             "partial" : "views/account/account.html", // partial file
             "controller" : "account/main" // RequireJS module
             "directives" : [ "directives/version", "directives/menu" ] // directives used in the view
        }
        ....
    }
}

This way you could:

  • develop the views in separation and the build the application based on this json bootstrap
  • have some common directives and components
  • when bootstrap after the login you could filter the views that user is allowed to see
  • everything inside the ngView would be loaded on demand

Of course your application should then be really big so that doing all of this additional work would made sense ;)

Upvotes: 8

Related Questions