Notes on Vue.js and MVVM

MVVM is the abbreviation of Model-View-ViewModel. It is an architectural pattern based on front-end development. Its core is to provide two-way data binding between View and View Model, which allows the state changes of View Model to be automatically passed to View. This is called two-way data binding.

Vue.js is a Javascript library that provides MVVM-style two-way data binding, focusing on the View layer. Its core is the VM in MVVM, which is ViewModel. ViewModel is responsible for connecting View and Model to ensure the consistency of view and data. This lightweight architecture makes front-end development more efficient and convenient.

Why does MVVM appear?

I came into contact with MVVM in 2015. It can be said that 2015 was the hottest year for MVVM. Before that, all I knew was MVC. I came into contact with MVC about 5 years ago, that is, in 2011. , I just learned programming language at that time, and I learned Java, and the classic SSH framework in Java was used to build a standard MVC architecture. To be honest, I have been using the MVC architecture for so many years, but I have never had a deep understanding of it. I only stayed at the level of use. It was not until I came into contact with Vue.js, studied the MVVM architectural ideas, and then looked back at MVC that I suddenly became enlightened. The feeling~

MVC is the abbreviation of Model-View-Controller, which is Model-View-Controller. In other words, a standard Web application is composed of these three parts:

View is used to convert data in some way. The way is presented to the user

Model is actually data

Controller receives and processes requests from users, and returns the Model to the user

In those years when HTML5 was not yet popular, MVC was OK as the best practice for web applications Yes, this is because the View layer of the Web application is relatively simple, and the data required by the front end can basically be processed by the back end. The View layer is mainly for display. At that time, Controller was advocated to handle complex business. logic, so the View layer is relatively lightweight, which is the so-called thin client idea.

From 2010 to 2011, the concept of HTML5 was hyped and sought after. In 2012, W3C officially announced that the HTML5 specification had been officially finalized. In 2013, when I first joined the company, I came into contact with Sench touch, an HTML5 framework. Sench touch is an HTML5 framework used to build mobile applications. It completely separates the front and back ends. The front end adopts the MVC architecture and is used as an independent project. maintain.

Why does the front-end need to be engineered if MVC is used?

Compared with HTML4, the biggest highlight of HTML5 is that it provides some very useful functions for mobile devices, making HTML5 capable of developing Apps. The biggest advantage of developing Apps with HTML5 is cross-platform, rapid iteration and launch, saving labor costs and Submission efficiency, so many companies began to transform traditional apps and gradually replaced Native pages with H5. By 2015, many apps on the market had more or less embedded H5 pages.

Since we want to use H5 to build the App, what the View layer does is not just simple data display. It must manage data, manage various statuses of user operations, and also handle various user operations on mobile devices. behavior and so on. Therefore, the front end also needs a framework similar to MVC to manage these complex logics and make development more efficient. But at this time, MVC has slightly changed:

View UI layout, display data

Model manages data

Controller responds to user operations and updates the Model to the View

This MVC architecture pattern is suitable for basic applications It seems OK, and it is in line with the layered thinking of software architecture. But in fact, with the continuous development of H5, people hope that applications developed using H5 can be comparable to Native, or close to the native App experience. Therefore, the complexity of front-end applications is no longer what it used to be. At this time, the front end exposed three important pain points:

1. Developers call a large number of the same DOM API in the code, which makes the processing cumbersome and redundant, making the code difficult to maintain.

2. A large number of DOM operations reduce the page rendering performance and slow down the loading speed, affecting the user experience.

3. When the Model changes frequently, developers need to actively update the View; when user operations cause the Model to change, developers also need to synchronize the changed data to the Model.
Such work is not only cumbersome, but also difficult Maintain complex and changing data status.
In fact, the early emergence of jquery was for the front-end to operate the DOM more concisely, but it only solved the first problem, and the next two problems always existed with the front-end.

The emergence of MVVM perfectly solves the above three problems.

MVVM is composed of three parts: Model, View, and ViewModel. The Model layer represents the data model, and business logic for data modification and operation can also be defined in the Model; View represents the UI component, which is responsible for converting the data model into UI display, and ViewModel It is an object that synchronizes View and Model.

Under the MVVM architecture, there is no direct connection between View and Model. Instead, they interact through ViewModel. The interaction between Model and ViewModel is two-way, so changes in View data will be synchronized to the Model, and Model data Changes will also be immediately reflected on the View.

ViewModel connects the View layer and Model layer through two-way data binding, and the synchronization between View and Model is completely automatic without human intervention, so developers only need to focus on business logic and do not need to manually operate the DOM. There is no need to pay attention to the synchronization of data status. Complex data status maintenance is completely managed by MVVM.

Details of Vue.js

Vue.js can be said to be the best practice of MVVM architecture. It focuses on ViewModel in MVVM. It not only achieves two-way data binding, but is also a relatively lightweight JS library. , the API is simple and easy to use. There are ready-made tutorials on the Internet for the basic knowledge of Vue, so I won’t go into details here. Let’s take a brief look at some implementation details of Vue.js about two-way binding:

Vue.js uses the getter and setter of Object.defineProperty, and combines them Observer pattern is used to implement data binding. When you pass a plain Javascript object to a Vue instance as its data option, Vue will iterate through its properties and convert them into getters/setters using Object.defineProperty. The getters/setters are not visible to the user, but internally they allow Vue to track dependencies and notify changes when properties are accessed and modified.

Observer data listener, which can monitor all properties of the data object. If there is any change, it can get the latest value and notify subscribers. It is implemented internally using the getter and setter of Object.defineProperty

Compile instruction parser , its role is to scan and parse the instructions of each element node, replace the data according to the instruction template, and bind the corresponding update function

Watcher subscriber, as a bridge connecting Observer and Compile, can subscribe to and receive each Notification of attribute changes, execute the corresponding callback function bound by the instruction

Dep message subscriber, internally maintains an array to collect subscribers (Watchers), data changes trigger the notify function, and then call the update method of the subscriber

When new Vue() is executed, Vue enters the initialization phase. On the one hand, Vue will traverse the properties in the data option and use Object.defineProperty to convert them into getters/setters to implement the data change monitoring function; on the other hand, Vue's The instruction compiler Compile scans and parses the instructions of the element node, initializes the view, and subscribes to Watcher to update the view. At this time, Water will add itself to the message subscriber (dep), and the initialization is completed.

When the data changes, the setter method in the Observer is triggered. The setter will immediately call Dep.notify(). Dep starts to traverse all subscribers and calls the update method of the subscriber. After the subscriber receives the notification, it will update the view. Make corresponding updates and complete a data binding.