Javascript dynamic loading 2

In the previous article on javascript dynamic loading, we mentioned using the synchronous loading policy to implement this method, as shown in figure
Copy codeThe Code is as follows:
Using ("jquery ");
Using ("User ");

$ ("# ID"). click (function (){
Var user = new User ();
User. name = "xx ";
User. show ();
});

Because Javascript is single-threaded, the synchronization policy has many disadvantages, such as blocking subsequent code execution and leading to Browser Spoofing.
It is difficult to implement the effect of using the asynchronous policy after the pilot package. It can only be implemented in the form of callback. This is not what UsingJS wants to implement. After all, jQuery's getScript function can implement this method.

After some consideration, we finally come up with a solution to solve the problem of importing packets asynchronously. Let's take a look at the programming method after using this solution.
Copy codeThe Code is as follows:
<Div id = "panel"> </div>

<Script type = "text/javascript" src = "js/using-0.4.js"> </script>
<Script type = "text/javascript">
Using ("jq ");
Using ("jq ");
Using ("Http ");

Using. asyn (function (){
$ ("# Panel"). click (function (){
Alert ("Using jquery object ");
});
Using. fetch ("Http", function (){
Var http = new Using. Modules. Http ();
Http. set ("xxx ");
Http. show ();
});
});
</Script>

As shown in the above Code, the synchronization policy is not significantly modified. It only imports jquery twice. Here, it is obviously necessary to process it only once and add a Using. asyn function, which will be analyzed later.
As we all know, the asynchronous policy does not affect the current running. If the imported package is being loaded and the subsequent code is also running, there is a dependency between the two, then an exception occurs. The only solution to solve the problem is the callback function.

According to the Using idea, it must be used after the pilot package. The asynchronous solution is to place the required JS file into an object, such as Array, before the module is used, load them one by one. Let's see.
Copy codeThe Code is as follows:
Using ("jq ");
Using ("jq ");
Using ("Http ");

How it works. Previous Code
Copy codeThe Code is as follows:
Var moduleList = [];

Using. fn = Using. prototype;
Using. fn. initialize = function (module ){
! This. exist (moduleList, module )? ModuleList. push (module): null;
}

This code skips the context and captures an initialization method in the Using prototype. It is known from the code that its main responsibility is to place the modules to be loaded into moduleList for judgment, if moduleList contains the module to be loaded, no operation is performed.

So when will it be loaded? The preceding Using. asyn method is used to notify Using. Now the file needs to be asynchronously loaded, and the callback function of the Using. asyn function is called after loading. Same previous Code
Copy codeThe Code is as follows:
Using. asyn = function (callback ){
Using. fn. script (callback );
}

From the code, we can only briefly see that the Using. asyn function calls the Using. fn. script Function and passes the callback function to it. Naturally, you need to see how it works.
Copy codeThe Code is as follows:
Using. fn. script = function (callback ){
Var _ this = this,
Complete = 0,
Count = moduleList. length,
Len = 0;
If (count <1 ){
Return;
}

Var loadScript = function (){
While (len <count ){
_ This. ajax (Using. Config [moduleList [len], function (){
Complete ++;
If (complete> = count ){
Callback ();
}
});
Len ++;
}
}
! Using. Config? _ This. ajax ("/js/config", function (){
LoadScript ();
}): LoadScript ();
}

First, check Using. Config, which is the module configuration file mentioned in the previous article, to notify Using to load the corresponding module file through the module name.

The second step is to use the internal function loadScript to load the module File and use a counter complete to determine that several modules have been loaded. When all modules are loaded, the callback function is called.

The whole idea of integrating the above Code is to export the package through the Using object, record it, and use the Using. asyn to notify Using to perform asynchronous loading, and finally Using. fn. script to asynchronously load and execute the callback function.

Also noted that Using. fetch function, the entire function is mainly to solve the file to be loaded when the code runs to a certain extent or a certain requirement, similar to $. before loading the getScript file, the system checks whether the required module has been loaded. If the required module has been loaded, the system directly executes the callback function.

This UsingJS change mainly aims to change the synchronization policy to an asynchronous policy, but there are also many issues left over, such as the need for a similar $ (document ). ready is executed only when the document is loaded. In itself, it is not difficult to achieve this effect. Instead, it is a messy mind when writing code, and there is no way to solve Using at the moment. asyn loads the same Module Multiple times due to asynchronous calls, or a variety of inexplicable problems. At the moment, there is no clue, so it will be postponed, step by step.

There is also the order of the import package, which cannot be any order. At that time, we wanted to create any import package and add dependencies to solve the loading order by code, but we thought again, this practice has no practical significance. The encoding personnel must know the dependencies between files. If the encoding personnel do not know the file loading order, they will use the <script> label format, as a result, errors will occur, and dependency creation not only increases the volume of Using, but more importantly, repetitive tasks. I don't know if this is correct.