This article is from my blog. This idea is not necessarily for the series, so, this idea is not necessarily for 😉

Everything is data (0,1), everything is quantifiable

Whether you want to admit it or not, the presentation of the page is a visualization of the data. HTML is data, CSS is data, JS is data. It’s just that the combination of data turns out to be what we want it to be.

Most intuitively, when we Enter any form of data in the Developer tool Console and press Enter, it will eventually show up below (provided the correct data type and format is entered). Or, if we request a JSON file from the service with some parameters, the contents will be displayed on the browser. Data => view, simple and straightforward.

primers

However, the reality is much more complicated than that. In order to better visual enjoyment and user experience, the page effect on the browser is more and more dazzling, and the interaction logic is more and more complex. The first-hand data we get (either from users or services) can no longer be directly used for presentation, but must be processed logically (here we call first-hand data source data, and the data after logical processing is called target data). The data on the view is a mapping of the target data.

And how should the processed data be presented? Do you do DOM based operations, or do you re-render based on the target data? The former is represented by jQuery, while the latter is dominated by newer frameworks such as Vue. An example is 🌰, implicit for a DOM element.

<!--jQuery -->
  <div id='jquery'></div>
$('#jquery').hide();

<!--Vue -->
  <div id='jquery' v-show={id[jquery]}></div>
data: {
  id: {
    jquery: fasle
  }
}
Copy the code

Based on DOM manipulation, we need to constantly manipulate the DOM to change the style if we need to change the implicit meaning of the DOM at any time. For data-based operations, we only need to change the value of jQuery.

Back to the topic, for complex interactive pages, the data => view relationship is not as pure as it used to be. To cope with complex scenarios, data and views are no longer narrowly defined. Data includes data and operations related to data, and views include views and operations related to views.

The MV * mode

Using the MV* frame pattern, data and views correspond to Model and View. The Model-View can handle a simpler page. But complex scenarios, models, and Views can share too much logic and become bloated, and may even contain logic that is not within their responsibility.

At this point, we need to use a third party to coordinate the relationship between Model and View. How to cooperate, in fact, there are already corresponding solutions. MVC, MVP, MVVM. Because the focus is always on coordinating the Model and View, they are collectively referred to as MV*.

MVC (Model -view -Controller), MVP (model-view-Presenter) and MVVM (Model-view-ViewModel) are both patterns and abstractions.

Each pattern may have different variations in practice, but that does not prevent them from belonging to the same pattern. Different variations of each model are created to solve different problems, so they are not superior or inferior.

Now let’s personify the three modes to illustrate how each mode works.

J-20 model powered by four batteries:

MVC

Company: Aircraft model manufacturer => produces aircraft models that can be self-shaped.

Pattern: MVC

Aircraft model V: A model produced from model data. Responsibilities: self-shaping from model data, collecting user feedback and forwarding.

Engineer M: Responsible for converting customer service demand parameters into the final model data. Responsibilities include: data manipulation, notification of aircraft model updates.

Engineer C: Coordinate M and V. Responsible for responding to users and calling engineer M to generate target data.

First of all, we need to know that the customer wants a 60cm * 60cm aircraft model. When the demand is presented to the manufacturer, it is definitely not a small box of 60cm * 60cm, but a real aircraft model based on the calculation and processing of the demand (such as what kind of modeling design can minimize the drag). One of the jobs of engineer M is to produce the final model data based on the original data and combined with specific logical rules.

Now, the user has a model airplane V, but the wings of the model airplane are different from what the user expected. The user then reported the problem in the manner provided on the model plane (for example, the model plane provided a message function to collect user feedback). After receiving the feedback, Engineer C pulls engineer M over to process the data and generate new model data, and asks Engineer M to inform aircraft models sharing the same data to update the data and adjust the data autonomously.

By the way, when it comes to adjustment, we have two ways. One is that we can make adjustments to the areas where users are unhappy (wings). One is, let’s format the airplane model and reinitialize it with the latest data model. The former can be thought of as DOM based manipulation and the latter as data based processing.

In MVC, the Model and View are coupled, and updates to the View need to be notified directly by the Model. The View can only be updated because there is a reference to the View inside the Model.

MVP

If the Model only wants to do data-related operations and moves the logic of the notification View to Control, the Control becomes Presenter. Because the Model and View are decoupled, their responsibilities are more clearly delineated.

Company: Aircraft model manufacturer => produces aircraft models that can be self-shaped.

Mode: the MVP

Aircraft model V: A model produced from model data. Responsibilities: self-shaping from model data, collecting user feedback and forwarding.

Engineer M: Responsible for converting customer service demand parameters into the final model data. Responsibilities include: operation of data.

Engineer P: Coordinate M and V. Responsible for responding to users, calling engineer M to generate target data and update views.

In MVP mode, engineer M’s job is to focus on data, leaving engineer P’s job to inform. In the same scenario as MVC, engineer P took engineer M over to process the data after receiving the feedback, and then asked the aircraft model to adjust autonomously according to the processed data. Actively notify the view of updates every time the data changes.

MVVM

It would also be easier for presenters if data changes could automatically trigger view updates. Presenters are called viewModels again.

Company: Aircraft model manufacturer => produces aircraft models that can be self-shaped.

Pattern: MVVM

Aircraft model V: A model produced from model data. Responsibilities: self-shaping from model data, collecting user feedback and forwarding.

Engineer M: Responsible for converting customer service demand parameters into the final model data. Responsibilities include: operation of data.

Engineer VM: Coordinate M and V. Responsible for responding to users, calling engineer M to generate target data and update views.

In MVVM, the View and Model don’t seem to change much. In order to update the view automatically when the data changes, the ViewModel performs what is called data binding. The ViewModel binds the target data to the view, and when the target data is finally generated, it triggers an update of the view.

Here we can imagine having two pieces of data, one source and one target. The binding to the view is the target data, so when we modify the target data directly, the view updates are triggered. If the source data is processed and assigned to the target data, the target data will also change and an attempt to update will be triggered.

In general, in MVVM, a view is a visualization of the target data, and by changing the data in the view, you change the target data.

The same scenario as MVC and MVP, but with technology, the engineer VM has an automated handler. The user reports the problem, and the engineer VM’s automatic processing program receives the feedback and sends the results to the model aircraft for self-adjustment.

Here is the MVVM schematic of Vue:

However, different variations are solutions to different problems, and there may be MVA, MVB… Who knows