I wanted to find out the difference between the .config and .run functions in AngularJS. I was using my .config for setting up routes, but I did have some $on's for watching route change start and success events.
I then moved some of this code to .run as I was having some dependency injection problems in .config.
I finally moved some of this to a CommonAppController which I have set on my <body>.
I also had 2 .config's and it seemed to be running ok, but surely this isn't right?
Can anyone give a little insight on which method to use?
Configuration blocks and run blocks get executed at different points in the application bootstrap, and have different injection locals at their disposal. Here's a summary of what you can find in the AngularJS documentation.
Configuration blocks (registered with module.config()) get executed during provider registration, and can only be injected providers and constants (see module.provider() and module.constant()). This is typically where you would configure application-wide stuff, such as the $routeProvider. Stuff that needs to be configured before the services are created.
Run blocks (registered with module.run()) get executed after the injector has all the providers. Now, all instances and constants can be injected. This is typically where you would configure services, $rootScope, events and so on.
You can have multiple of either, and they are executed in the order they were registered to the module. Some people prefer to register a configuration block before every group of controllers to register the routes to these controller, for example.
The .config block is executed during the provider registration and configuration phase. It' a module level block.
The.run block is executed after the config block. It's used to inject services and constants.
Related
I need to call a function before the window load event fires. Is there another transition method I can call to guarantee my function is executed before the window load event fires?
In Angularjs, you can use .config or .runmethods attached to you module. They will execute before your controller.
From ngDoc : https://github.com/angular/angular.js/blob/ce669edfa14dc7eb7c389d2f82c9c98399a9009b/docs/content/guide/module.ngdoc#LC122
Configuration blocks - get executed during the provider registrations and configuration
phase. Only providers and constants can be injected into configuration blocks. This is to
prevent accidental instantiation of services before they have been fully configured.
Run blocks - get executed after the injector is created and are used to kickstart the
application. Only instances and constants can be injected into run blocks. This is to prevent
further system configuration during application run time.
Usage :
angular.module('myapp', [])
.config(function() {})
.run(function() {});
I am working with angularJS routing. In this regard I need documentation of .run() function.What is the responsibility of .run() function.Thanks
From the docs
Run Blocks
Run blocks are the closest thing in Angular to the main method. A run
block is the code which needs to run to kickstart the application. It
is executed after all of the services have been configured and the
injector has been created. Run blocks typically contain code which is
hard to unit-test, and for this reason should be declared in isolated
modules, so that they can be ignored in the unit-tests.
run() is also the earliest you will have access to $rootScope. It is a good place to register states and routes.
I'm pretty new to AngularJS, so far I have learnt that providers are used to configure the services that will be used later during the execution phase. Particularly, routes are configured during the configuration phase using $routeProvider and then we can access the routes in our controller using the service $route.
I would like to know if once I have set up the routes with $routeProvider, if it's possible to modify the routes, add new ones or delete existing ones using the service $route (during the execution phase). So basically if we can have a kind of dynamic routes, and if so, how can we achieve this.
Thank you!!
nope, the $route service is configured during the config phase via the $routeProvider service, and this phase happens only once when starting the app.
If you want to add dynamic behavior to the url, you ca still manipulate the search parameter thanks to $location.search().
(and then $watch the changes or whatever you want to do)
I have a number of services defined within an AngularJs application. There is a root service that must load, get some data from a server, then the other services that depend on this root service can initialise, and after that the controllers can load and display data on the page.
Th problem is controllers are loading before the root service, and child services, can fully initialise, eg:
User loads page
root service starts initialisation
controller loads, which depends on child service (which depends on root service)
page binding fails because child service cannot supply data to controller
root service finishes intialisation (too late)
The initialisation flow I want is this:
User loads page
root service starts initialisation
root service finishes intialisation
child services which depend on root service initialise
controller loads, which depends on child service
page binding succeeds
Is there a technique for handling this kind of problem?
From Angular docs https://docs.angularjs.org/guide/module
A module is a collection of configuration and run blocks which get applied to the application during the bootstrap process. In its simplest form the module consist of collection of two kinds of blocks:
Configuration blocks - get executed during the provider registrations and configuration phase. Only providers and constants can be injected into configuration blocks. This is to prevent accidental instantiation of services before they have been fully configured.
Run blocks - get executed after the injector is created and are used to kickstart the application. Only instances and constants can be injected into run blocks. This is to prevent further system configuration during application run time.
angular.module('myModule', []).
config(function(injectables) { // provider-injector
// This is an example of config block.
// You can have as many of these as you want.
// You can only inject Providers (not instances)
// into config blocks.
}).
run(function(injectables) { // instance-injector
// This is an example of a run block.
// You can have as many of these as you want.
// You can only inject instances (not Providers)
// into run blocks
});
Try this.
I've been trying to get into the nitty-gritty with angular DI and really the bootstrap process at large, and I am a bit confused as to where things really happen. In my mind, the events are in this order.
App starts.
$provider registers service providers.
In the config phase, the providers can be configured.
Now is where I am lost.
The $injector, now having access to all the configured providers from $provide, calls the constructor functions (the $get function in each provider) to instantiate service instances.
Also, if that process is correct, how does the $injector handle cases where a service depends on another service?
Services are only instantiated at the moment when they are needed, rather than during Angular's initiation. For example, if you have a controller that isn't activated yet and it depends on services which haven't yet been used, those services will be instantiated and injected whenever that controller becomes active (like changing to a view that uses it). From then on, the same instance of each service will be used.
The same is true of services that depend on other services. All dependencies of anything are resolved before it is instantiated, so if a dependency has dependencies, the same process is applied (all of that dependency's dependencies will be instantiated first, and so on).
If a circular dependency is found (service foo has a dependency that depends on service foo), Angular will throw an exception and the functionality of those services will have to be refactored into different services that will not have this kind of circular chain.