JLA framework introduction (2) core and basic specifications

This article will introduce the core of the JLA framework. Before that, we will introduce the "JLA" name, full name: "javascript lazy app". The core of this framework is a series Code The Unit is combined and loaded on the page as needed, that is, the commonly mentioned "lazy loading", which is the origin of this name. When we carefully examine the features of JavaScript against other languages, we will find that security and support for lazy loading are a feature that we cannot ignore, security means that users usually trust the operation of JavaScript scripts. Therefore, the platform is widely run, while lazy loading allows us to flexibly control the operation during development. Program The process that the unit flows from the server to the client. In this way, it is possible to develop large projects using JavaScript. Nowadays, more and more desktop applications are changing to the BS mode. The original applications may be dozens or even hundreds of megabytes. In this case, if all the functions are loaded to the page in BS mode at a time, it will bring a very bad user experience to the client, and the pressure on the server is also great, in addition, most of these functions may not be usable by users. Therefore, we 'd better split the program and load any function as needed, such as the operation executed after clicking the button. The JLA framework is designed to solve this problem. Let's first look at how the framework is defined: In the JLA framework, a program consists of a large number of code units, each code unit should be in this mode:
1 JLA. Require ([ " Namespace. classa " , " Namespace. classb " ], 2 , Function (Classa, classb)
2 {
3 // Code of classd start
4 Function APP ()
5 {
6 }
7 App. Prototype. onclick = Function ()
8 {
9 JLA. Require ([ " Namespace. classc " ], 1 , Function (Classc)
10 {
11 // Call classc.
12 })
13 }
14 // Code of classd end
15 JLA. Set ( " Namespace. classd " , APP );
16 })

 

 

From the code unit above, this code Unit defines a class. The namespace of this class is namespace. classd, through JLA. set to register this namespace with the framework. This class uses two JLA. the require method indicates that this class will depend on other classes at runtime. When a class needs to call other classes, JLA. require mode. This mode has three parameters: parameter 1 is a namespace array, which indicates which class parameters need to be called. 2 is the dependent type and there are three types: value 1 indicates that the class should be obtained immediately and the callback function should be executed after the class is obtained. It is mainly used when the class needs to be loaded lazily, for example, if the value 2 of the function executed after clicking the button has the same meaning as 1, we recommend that you package these classes when releasing the code (meaning the dependency is too high, dynamic Loading is not recommended. It is mainly used when one class must reference another class to run. The value 0 indicates that the class does not need to be loaded, however, if the class has been loaded or is referenced by other classes later, the callback function is executed, which is rarely used and mainly used in event binding. Parameter 3 is a callback function. After all required classes are loaded, the callback function is automatically executed and the list of required classes is passed as parameters of the callback function, in this way, you can directly use those classes without re-execution. Although the above code is very simple, JLA is actually used. require And JLA. set two functions, but this code already fully expresses the core specifications of the JLA framework. I will briefly describe the specifications defined by this core: 1. do not call a class directly. References to external class should be passed through JLA. require, although you may directly use the namespace or JLA. get (namespace) calls that class, because it breaks the specification, and if the class has not been loaded yet, an exception will occur; 2. each code unit should specify the classes to be depended on and the degree of dependency in the process of implementing its own logic. Only those classes can be clarified, in order to ensure that the final application will only load the required logical unit; 3. each class should only care about its own implementation logic, instead of the final program, so as to ensure that each Code unit reusability. This framework specification is relatively simple. It may be difficult to develop with this framework, but it is actually a complete development framework. I will continue to describe more content later, however, all applications that rely on this framework are not complementary to this framework.