You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If you need to have more control over the initialization process, you can use a
manual bootstrapping method instead. Examples of when you'd need to do this include
using script loaders or the need to perform an operation before Angular compiles a page.
Here is an example of manually initializing Angular:
Note that we have provided the name of our application module to be loaded into the injector as the second parameter of the api/angular.bootstrap function. Notice that angular.bootstrap will not create modules on the fly. You must create any custom modules before you pass them as a parameter.
This is the sequence that your code should follow:
After the page and all of the code is loaded, find the root element of your AngularJS application,
which is typically the root of the document.
Call api/angular.bootstrap to compile the element into an executable, bi-directionally bound application.
When Angular library is loaded it will scan the DOM looking for element with ng-app directive.
When it finds one it will begin the bootstrapping proces.
In that process Angular will take the value of ng-app attribute (in your case that's InventoryModule)
and will try to find an angular module with the same name. If it fails it will throw:
Uncaught Error: No module: <module name>.
In your fiddle you have set the "Code Wrap" select box to "onLoad". This drop-down instructs
jsFiddle when to initialize the JS code that you've put in JS frame. When it's set to "onLoad",
the code will run in onLoad window event.
On the other hand, Angular bootstrapping process will run on $(document).ready(), and because
$().ready event is fired before "onLoad" event, Angular will try to init the InventoryModule module
before the module is even defined, and that's where the dreaded "No module" error will be thrown.
angular.bootstrap() is a manual way of doing the same thing that Angular already does in it's $().ready() handler.
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 the 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 the run blocks
});
Configuration Blocks
There are some convenience methods on the module which are equivalent to the config block. For example:
The configuration blocks get applied in the order in which they are registered. The only exception to it are constant definitions, which are placed at the beginning of all configuration blocks.
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 service 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.