AngularJS implements on-demand asynchronous loading of instance code _ AngularJS

This article mainly introduces the information about how AngularJS can asynchronously load instance code as needed. For more information about how AngularJS supports multi-view applications through routing, You can dynamically load the desired view based on routing, the AngularJS documentation provides a detailed introduction. There are also many tutorials on the Internet, so you don't need to introduce them!

As the number of views increases, the number of js files increases. AngularJS loads all js files at one time by default, which is inconvenient to use. Therefore, the demand for Loading modules on demand will become stronger and stronger, however, AngularJS does not implement on-demand loading.

I used to seajs's asynchronous loading method, and thought angular could also use asynchronous loading, but this is not the case.

Like requirejs, angularjs uses a pre-loaded mode to organize modules (this is the opposite of seajs's lazy loading). When there are more and more modules for a single page application, this means that more and more modules need to be pre-loaded, which may indicate that angular is more suitable for lightweight application development.

Official start

I used angular-ui-router for routing. The module loader is requirejs.

// Route {state: 'login', templateUrl: 'login/login.html ', controller: 'loginctrl', resolve: {realCtrl: function ($ q) {var def = $ q. defer (); require (['/features/login. js'], function (loginCtrl) {def. resolve (loginCtrl)}); return def. promise ;}}, // get $ controllerProviderapp. config (function ($ controllerProvider) {app. registerController = $ controllerProvider. register ;//...}) // loginControlerapp. registerController ('loginctrl ', function ($ scope) {// do something });

Angular Application Implementation On-Demand Loading Method

One of our systems is developed with angular and is a single page application. With the iteration of the system, the code on the first screen is too large, so the system is transformed.

We mainly face three problems

1. Does the module need to load the framework?

2. How do I register the page components asynchronously loaded?

3. When can I load page components?

For the first problem, angular has a set of modular solutions, and the introduction of the module loading framework is somewhat redundant, and the overall transformation volume is large, so we will not consider it.

Therefore, we only implemented a loadscript method to load components. It is worth noting that when loading multiple files in a series of parallel lines, and avoid repeated loading during page switching.

The second problem is quite painful. angular has a saying that "startup" occurs after domcontentloaded and all dependencies injected into the main module are compiled.

If you want to use APIs such as controller and deractive after startup, an error is reported.

Currently, there is only one way to solve this problem, that is, to actively register the controller using the provider of the main module, but since the provider cannot be used directly, we store it under the main module.

The stored method can be used to register the page components asynchronously loaded. The disadvantage is that all sub-pages are mounted under the main module.
To address the third problem, because the operating platform is a single page application, the best loading time should be when the route listens for hash changes, but because our route is a static configuration, at first, no good solutions were found.
Later I found such an api

Probably, before $ routeChangeSuccess, we can also do something to put the loading time here, which is the best choice.
The specific implementation is probably like this

So far, this solution is ready. What is the work left?
1. Sort out the code to make the code more generic. We will develop a new page later, just write it in route configuration.

2. rebuild existing pages. Because there is no on-demand loading before, the service coupling between different pages is very serious. In the future, we will develop new pages. It is best to place the services shared between different pages under component.

3. Change the build and replace the js reference in the route with the cdn path.