Before talking about the angularjs module, let’s first introduce some knowledge points of angular:
AngularJS is a pure client technology, written entirely in Javascript. It uses conventional technologies of web development (HTML, CSS, Javascript) to make web application development faster and easier.
AngularJS simplifies application development is to package some common low-level development operations to provide them to developers. AngularJS will automatically handle these low-level operations. They include:
operate
2. Set up the listening of events
3. Input verification, because AngularJS will handle most of these operations, developers can focus more on the application's business logic and write less repetitive, error-prone, and low-level code.
While AngularJS is simplifying development, it also brings some exquisite technologies to the client, including:
1. Separation of data, business logic, and views
2. Automatic binding of data and views
3. General Services
4. Dependency injection (mainly used for aggregation services)
5. Extensible HTML compiler (written entirely by JavaScript)
6. Easy to test
7. The client's demand for these technologies has actually existed for a long time.
At the same time, you can also use AngularJS to develop single-page or multi-page applications, but it is mainly used to develop single-page applications. AngularJS supports browser history operations, forward and back buttons, and favorite operations in single-page applications.
Next, let’s explain the module of angularJS in detail.
Most applications have a main method for instantiating, organizing, and launching applications. AngularJS applications do not have a main method, but use modules to declare how the application should be started. This method has the following advantages:
1. The startup process is declarative, so it is easier to understand.
2. In unit testing, there is no need to load all modules, so this method helps write unit tests.
3. Additional modules can be added to tests in specific situations. These modules can change configurations and can help with end-to-end testing.
4. Third-party code can be packaged into reusable modules.
5. Modules can be loaded in any order of sequence or parallelism (because the execution of the module itself is delayed).
For example:
<!doctype html>
<html ng-app="myApp">
<head>
<script src="/angular-1.0."></script>
<script>
var myAppModule = ('myApp', []);
// configure the module.
// in this example we will create a greeting filter
('greet', function() {
return function(name) {
return 'Hello, ' + name + '!';
};
});
</script>
</head>
<body>
<div>
{{ 'World' | greet }}
</div>
</body>
</html>
In the above example, we use the myApp module to start the application by specifying it in <html ng-app="myApp">.
The above example is very simple to write, but it is not suitable for writing large applications in the same way. Our recommendation is to split your application into the following modules:
1. A service module used to make service declarations.
2. An instruction module used to make instructions declarations.
3. A filter module used to make filter declarations.
4. An application-level module that depends on the above modules, which contains the initialization code.
For example:
<!doctype html>
<html ng-app="xmpl">
<head>
<script src="/angular-1.0."></script>
<script src=""></script>
</head>
<body>
<div ng-controller="XmplController">
{{ greeting }}!
</div>
</body>
</html>
[/code]
:
[code]
('', []). //Service module value('greeter', { //Custom greeter object salutation: 'Hello',
localize: function(localization) {
= ;
},
greet: function(name) {
return + ' ' + name + '!';
}
}).
value('user', { //Custom user object load: function(name) {
= name;
}
});
('', []); //Instruction module('', []); //Filter Module('xmpl', ['', '', '']). //Module xmpl depends on modules in array run(function(greeter, user) {
// Initialize the code, it will be automatically executed when the application starts ({
salutation: 'Bonjour'
});
('World');
})
// A Controller for your app
var XmplController = function($scope, greeter, user) {
$ = ();
}
The reason for this split is that you often need to ignore the initialization code in your tests, because these codes are more difficult to test. By splitting it out, it can be easily ignored in testing. The test can also be more specific by loading only modules related to the current test. The above is just a suggestion, you can rest assured to adjust it according to your specific situation.
A module is a collection of a series of configurations and code blocks that are attached to the application at the startup stage. A simplest module consists of two sets of code blocks:
Configuration Code Block - Execute during the injection provider injection and configuration phase. Only the injection provider and constants can be injected into the configuration block. This is to prevent the service from being initialized in advance before it is configured.
Run code block - executed after the injector is created and used to start the application. Only instances and constants can be injected into the run block. This is to prevent the system configuration from occurring after operation.
Code implementation:
('myModule', []).
config(function(injectables) { // provider-injector configuration code block// 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 runs the code block// 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
});
Modules also have some easy ways to configure, and using them is equivalent to using code blocks. For example:
('myModule', []).
value('a', 123).
factory('a', function() { return 123; }).
directive('directiveName', ...).
filter('filterName', ...);
// is same as
('myModule', []).
config(function($provide, $compileProvider, $filterProvider) {
$('a', 123)
$('a', function() { return 123; })
$('directiveName', ...).
$('filterName', ...);
});
The configuration blocks will be applied in the order of registration in $provide, $compileProvider, $filterProvider, and $filterProvider. The only exception is the definition of constants, which should always be placed at the beginning of the configuration block.
Running blocks are the most like the main method in AngularJS. A run block is a piece of code used to start the application. It is executed after all services are configured and all injectors are created. Running blocks usually contain some hard-to-test code, so they should be written in separate modules so that they can be ignored during unit testing.
A module can list other modules as its dependencies. "Depend on a certain module" means that the dependent module needs to be loaded before the module. In other words, the configuration block of the dependent module will be executed before the configuration block of this module. The same goes for running blocks. Any module can only be loaded once, even if it is dependent on multiple modules.
A module is a method used to manage $injector configuration and has nothing to do with the loading of the script. There are many libraries for loading control modules on the Internet, which can be used with AngularJS. Because modules do nothing during loading, they can be loaded in any order or in parallel