What is modular development and on-demand loading
What is modular development?
In order to answer this question, first explain what a "module" is: A
"module" is a section of program or subroutine required to complete a function. The module is the "single responsibility" and "replaceable" part of the system.
The so-called modularity refers to dividing the system code into a series of modules with single responsibilities and replaceable ones. Modular development refers to how to develop new modules and reuse existing modules to realize application functions.
What is on-demand loading
On-demand loading needs to be understood from both time and space.
Spatially: Only load the modules of the current page.
Temporal: Only load related modules when the user shows the intent of a certain function.
Applicable scenarios
for modular development and on-demand loading Applications that meet the following conditions are suitable for modular development and on-demand loading technology:
complex applications. More than one functional part, these parts may share some underlying code and
need long-term maintenance. In the early stage of development, the requirements may be unclear, and continuous iterative development is required, often facing demand changes and feature additions.
Demanding performance requirements. Facing complicated yoghurt interaction and data display problems.
What is the traditional js development model and loading model?
In the past, due to the low complexity of applications, js has always been an auxiliary program for web pages, not even an application development language. Moreover, most websites are one-time applications and are small in scale. Compared with maintainability, development speed is more important. Rather than refactoring an existing application, it is better to rewrite one. In such an environment, the traditional process-oriented programming model is sufficient to meet development needs.
Due to the small scale of the website, instead of dividing the code into small modules and loading them on different pages, it is better to write all relevant codes in one place, such as writing a common.js or share.js, and then all the pages. All cite this file. This is simple to develop, and because the browser has a cache, after the first load, there is no need for subsequent network transmission, and there will be no major problems in performance.
Problems with traditional development models.
Problem 1: Because the code organization structure is non-modular, the code cannot be reused, which leads to code duplication, which lays a hidden danger for maintenance-changes in requirements or addition of functions will lead to multiple changes in the code, as the application scales The increase of the code will quickly enter a state that is difficult to maintain.
Problem 2: Because the code granularity is too large, the page may load a large amount of code that is not used at all. Even if the network transmission problem is ignored, too much useless code will cause the page to parse slowly.
Problem 3: Since all the codes are mixed and cannot be tested, we cannot obtain effective means to ensure the quality of the code.
Why Modular Development and On-Demand Loading
Need
for Maintainability One understanding of maintainability of code is that the addition of new functions does not require modification of existing codes, and the changes of old functions do not require modification of multiple codes.
For projects whose initial requirements are not clear and need to be developed in an iterative manner, code maintainability is particularly important.
The need
for testability One understanding of the testability of code is that the code can be independently verified for correctness outside the system environment. It is very important to test the code outside the system environment. This not only ensures the correctness of the code, but also ensures that the code can be reused in different environments.
Performance needs
Modular code can be loaded on demand, thus ensuring that we will not waste valuable page loading time on downloading and interpreting redundant code.
Architecture requirements
One of the tasks of the architecture is to ensure that the system can cope with future changes. These changes include the addition of new functions, the modification of original functions, the replacement of strata library files (with jQuery switching to tangram or other), performance optimization, and so on. Any architecture that can achieve this goal requires the code to be modular.
Code reuse
Code reuse is not only to save development time, but also an effective means to ensure code quality. The higher the degree of code reuse, the easier it is to guarantee its quality.
The need for multi-person collaboration.
Large-scale applications cannot be completed by one person, and multi-person collaboration is inevitable. In a multi-person collaborative environment, you often have to modify or use the code written by others. Only those with single function, clear interface and modular code can we dare to modify or use it boldly.
Theoretical basis of
modular development Modular development is a development model that any large-scale application must adopt. Like the development of other applications, to achieve js modular development, we need to understand the following theoretical basis.
Object-oriented
Compared with the process-oriented programming model, object-oriented advocates constructing our programs with a cognitive model that is more in line with the real world, rather than understanding the problem model from the perspective of a computer. Its core ideas are "encapsulation", "inheritance" and "polymorphism". For js modular development, the idea of "encapsulation" is the most important. "Encapsulation" refers to hiding logic, methods, or properties that should not be exposed to other code inside the object (module). Only necessary interfaces are provided externally. In turn, the high cohesion and low coupling of the code are ensured. JavaScript is not a pure object-oriented language, it combines the ideas of process-oriented, object-oriented, and functional programming language, which also leads to the complexity of this language.
Design pattern
The problem to be solved by design pattern is how to organize and coordinate different objects to solve program problems. It is not the responsibility of this article to fully introduce design patterns. Here are just a few simple examples.
Singleton mode. Singleton mode refers to ensuring that there is only one instance of a class during the running of the program. Since JavaScript does not have the concept of a class, the application of the singleton mode is actually to ensure that a certain functional object is always the same object during the operation of our program, rather than being created repeatedly every time.
Subscriber mode. This is the most widely used mode in JavaScript. We add event listeners to the dom node through addEventListener or attachEvent, which is actually in the application subscriber mode. The subscriber mode allows a group of objects to listen to the events of an object to achieve one-to-many communication between objects, which reduces the coupling between objects to the greatest extent.
Appearance mode. The appearance mode encapsulates the interfaces of one or a group of objects, and only provides the interfaces required by other codes to the outside, so as to achieve the task of reducing code coupling.
How to practice
CommonJS. JavaScript does not have built-in module support, and the CommonJS specification gives a complete way to implement modules in JavaScript.
Front end support. There are a large number of mature js on-demand loading frameworks available, seajs is recommended here. See "References" for details.
Back-end support. The modular code needs to be packaged and compressed before it goes online. The package process requires static analysis of the source code to obtain the dependencies between modules, and then package related modules together. The spm tool provided by Seajs can automate this task.
Understanding of MVC\MVVM\MVVC
MVC (Model-View-Controller)
Model: The data layer is responsible for storing data.
View (view): presentation layer, the page that the user sees
Controller (controller): coordination layer, responsible for coordinating Model and View, make corresponding changes on the Model according to the user's actions on the View, and return the changed information at the same time Go to View.
The relationship between the three
Controllers can directly access the Model, or directly control the View, but the Model and the View cannot communicate with each other, which is equivalent to the COntroller being the coordinator between the two.
MVVM (Model-View-ViewModel)
Model: The data layer is responsible for storing data.
View (controller): is the ViewController layer, his task is to get data from the ViewModel layer, and then display.
ViewModel (view model): It is the glue between the View and Model layers, encapsulating business logic processing, encapsulating network processing, and encapsulating data caching. It is to separate the business logic and page logic of the original ViewController layer and put them in the ViewModel layer.
MVVC (Model-View-View-Controller)
Model: The data layer is responsible for storing data.
View (view): display layer, create requirements to create cell
View (view): define an array to receive the data in control. Processing callbacks (such as: refresh callback, click cell callback, load more callbacks, dynamic view height callback, etc.)
Controller: load network data lazy loading