You can inject $routeParams (requires ngRoute) into your controller. Here's an example from the docs:
// Given:
// URL: http://server.com/index.html#/Chapter/1/Section/2?search=moby
// Route: /Chapter/:chapterId/Section/:sectionId
//
// Then
$routeParams ==> {chapterId:1, sectionId:2, search:'moby'}
EDIT: You can also get and set query parameters with the $location service (available in ng
), particularly its search
method: $location.search().
$routeParams are less useful after the controller's initial load; $location.search()
can be called anytime.
You need to be aware about how AngularJS works in order to understand it.
Digest cycle and $scope
First and foremost, AngularJS defines a concept of a so-called digest cycle. This cycle can be considered as a loop, during which AngularJS checks if there are any changes to all the variables watched by all the $scope
s. So if you have $scope.myVar
defined in your controller and this variable was marked for being watched, then you are implicitly telling AngularJS to monitor the changes on myVar
in each iteration of the loop.
A natural follow-up question would be: Is everything attached to $scope
being watched? Fortunately, no. If you would watch for changes to every object in your $scope
, then quickly a digest loop would take ages to evaluate and you would quickly run into performance issues. That is why the AngularJS team gave us two ways of declaring some $scope
variable as being watched (read below).
$watch helps to listen for $scope changes
There are two ways of declaring a $scope
variable as being watched.
- By using it in your template via the expression
<span>{{myVar}}</span>
- By adding it manually via the
$watch
service
Ad 1)
This is the most common scenario and I'm sure you've seen it before, but you didn't know that this has created a watch in the background. Yes, it had! Using AngularJS directives (such as ng-repeat
) can also create implicit watches.
Ad 2)
This is how you create your own watches. $watch
service helps you to run some code when some value attached to the $scope
has changed. It is rarely used, but sometimes is helpful. For instance, if you want to run some code each time 'myVar' changes, you could do the following:
function MyController($scope) {
$scope.myVar = 1;
$scope.$watch('myVar', function() {
alert('hey, myVar has changed!');
});
$scope.buttonClicked = function() {
$scope.myVar = 2; // This will trigger $watch expression to kick in
};
}
$apply enables to integrate changes with the digest cycle
You can think of the $apply
function as of an integration mechanism. You see, each time you change some watched variable attached to the $scope
object directly, AngularJS will know that the change has happened. This is because AngularJS already knew to monitor those changes. So if it happens in code managed by the framework, the digest cycle will carry on.
However, sometimes you want to change some value outside of the AngularJS world and see the changes propagate normally.
Consider this - you have a $scope.myVar
value which will be modified within a jQuery's $.ajax()
handler. This will happen at some point in future. AngularJS can't wait for this to happen, since it hasn't been instructed to wait on jQuery.
To tackle this, $apply
has been introduced. It lets you start the digestion cycle explicitly. However, you should only use this to migrate some data to AngularJS (integration with other frameworks), but never use this method combined with regular AngularJS code, as AngularJS will throw an error then.
How is all of this related to the DOM?
Well, you should really follow the tutorial again, now that you know all this. The digest cycle will make sure that the UI and the JavaScript code stay synchronised, by evaluating every watcher attached to all $scope
s as long as nothing changes. If no more changes happen in the digest loop, then it's considered to be finished.
You can attach objects to the $scope
object either explicitly in the Controller, or by declaring them in {{expression}}
form directly in the view.
Further readings:
Best Answer
They are roughly the same, with a few differences:
This will work if you have your scripts loaded at the end of the page (instead of in the header).
Otherwise, the DOM will not be loaded at the time of bootrsaping the app (there won't be any template to be compiled, the directives won't have any effect).
This one works: plnkr
This one doesn't: plnkr
The same as before, using
body
as the root of the application. It uses a selector that is not available in jqLite, so you need to have full jQuery included in the app.I'm not sure what is the advantage of using
body
insteaddocument
, but probably has something to do with e2e testing, as explained in this commentplknr
This one actually waits for the DOM to be loaded, so it will work even if you include your scripts in the header.
This is basically the same as jQuery's
$(document).ready(
, but usingjqLite
'sangular.element
.In the last example, no modules are being passed to the bootstrap function, most likely you will need to declare your main module, unless your app consists only on controllers in the global namespace.
So the last option will be like the following, in order to be similar to the other two:
plknr
I guess that most of the time the safest bet is using this last approach.