As with all applications there has to be a starting point. Where does the application start? In AngularJS that starting point is the module.
And because a module is, well, modular, you can plug modules into each other to build the application, share components and so on.
Actually, I suppose in Angular it actually starts with a directive, that points to the module to start with, because, if you have more than one, which one do you start with?
ng-app directive bootstraps the application by telling AngularJS which module contains the root of the application.
A module is defined like this:
The name of the above module is "angularCatalogue", the name of the application, which is what is placed in the
ng-app directive in the html element previously.
You can also add as a second parameter to the module an array of other modules to inject. The modules don’t necessarily have to be loaded in any particular, so it is okay to refer to a module that may not exist at that point.
The module function returns a Module object, which you can then set up as you need it. Typically an application will have some sort of configuration, controllers, directives, services and so on.
Wiring up the view
In the html you will need to indicate where the view is to be placed.
You can do this via the ng-view directive, which can look like this:
Everything inside the element will be replaced with the contents of the view.
The application then needs to be told where the view is. You can configure the application module with that information, like this:
config call on the module allows the module to be configured. It takes an array that consisted of the names of objects to be injected into the configuration and the function that performs the configuration.
The function has a
$routeProvider injected into it. This allows routing to be set up. In the example above a route is set up from the home page of the application (
"/") that inserts the given template into the element (
ng-view) that designated the view and it uses the given controller.
I’ll move onto controllers in an upcoming post.
A note on the dependency injection
You’ll notice that there is no array, it is just taking a function. Angular can work out from the parameter names what needs to be injected. However, if the code is minified most minifiers will alter the parameter names to save space in which case angular’s built in dependency injection framework fails because it no longer knows what to resolve things to. Minifiers do not, however, minify string literals. If the string literals exist then it will use them as to determine what gets resolved into which parameter position. The strings must match the position of their counterpart in the function parameters.
Therefore the minifier friendly version of the previous snippet becomes:
A note on naming conventions
You can name things what you like but AngularJS has some conventions reserved for itself.
- Its own services are prefixed with a
$ (dollar). Never name your services with a dollar prefix as your code may become incompatible with future versions of angular.
- Its own directives are prefixed with
ng. Similarly to the previous convention, don’t name any of your directives with an
ng prefix as it may clash with what’s in future versions of angular.
myPersonalDirective when that directive is placed in HTML it becomes