Uncover the technical features of mini program development through programming mode

Since the birth of mini programs, many people have begun to study the mechanisms and characteristics of mini programs. From the perspective of source code and overall architecture, there are many good articles that will benefit people.

But theory is one thing. To truly understand mini programs, you still need a certain amount of practice to further understand some of the ideas behind mini programs, some of the similarities and differences between it and existing platforms, and how to adapt to it and make more interesting mini programs.

Mini-program programming mode

Recently, while developing the mini-program applications of "Qingmang Mini-Program+" and other Qingmang products, we have gained a further understanding of mini-programs, which led to this article.

To understand the characteristics of a development platform, a good angle is to start with the " programming mode ", that is, to see how to write and organize your own code when developing on this platform, and then figure out three questions:

• How to obtain data
• How the interface is presented
• How interaction is conducted

In other words, it is to disassemble the characteristics of this platform from the perspective of MVC (Model-View-Controller) so as to understand the characteristics of development on this platform.

How to obtain data?

The essence of a program is the presentation and processing of data. Therefore, to see the basic capabilities of a client development platform, first of all, we need to see what data can be placed on it for processing and what limitations it has. If the necessary data acquisition methods are missing, then for developers, even the best cooks cannot cook without rice.

From this point of view, the data acquisition methods provided by the mini program are very rich, roughly covering:

Get data from the server through Https request . Supporting Http is the most basic. Mini Programs have restrictions on Http. In addition to requiring the communication protocol to be Https and the domain name to be preset in advance, the application layer protocol is also limited to the Json format. This may be more stringent than any existing client platform. From the perspective of the Mini Program platform, such protocol regulations provide stronger control over the data flowing in the application; for developers, they need to spend some time adjusting their service protocols to adapt to the requirements of the Mini Program.

Data can be stored and accessed on the local file system . Mini programs provide a relatively rich set of APIs for developers to store and access files on the mobile phone system. Developers can use local files for caching, state memory, etc., which provides great convenience for development.

It can read and write some information in the device . The mini program opens some APIs to help developers obtain some basic information on the device, such as: phone model, screen size, network status, etc. What is more valuable is that it can choose to obtain multimedia files such as pictures on the phone, which provides the possibility of making some image-related applications; and it also provides a lot of information related to the device's compass, gravity sensor, geographic location, etc., which is very helpful for developers to understand the user's environment.

From the above introduction, it is not difficult to see that the data acquisition method in the mini program is similar to that provided by general browsers (that is, the information that can be obtained by HTML5 applications). It is more limited than the native client, but it is sufficient for most applications.

In addition, mini programs provide some data in the WeChat ecosystem , such as account information. This is only a very small part of the data in the huge WeChat ecosystem, but it is indeed the most valuable part of the data for developing mini program applications.

For example, on other platforms, if you need to obtain WeChat account information, you need to obtain user authorization once. If the user does not want to provide it temporarily, the program will be in the "not logged in" state, which will make it difficult to launch the entire service. In the mini program, as long as the user clicks on the mini program, it means that the authorization is completed. The developer can directly read the account information of the mini program and synchronize it to his own server as the identity of the user, thereby achieving the "always logged in" state, so that subsequent services can be better provided.

A possible example is as follows:

 // First call the login interface to get the request code   
 
 wx.login({ 
 
 success: function (res) { 
 
 // Get the request code and continue to request the user's basic information   
 
 var code = res.code 
 
 wx.getUserInfo({ 
 
 success: function (res) { 
 
 // Get the encrypted user information, decrypt and store it on the server   
 
 var userData = res.encryptedData 
 
 var iv = res.iv 
 
 wx.request({ 
 
 url: 'https://my_account/...' , 
 
 data: { 
 
 code: code, 
 
 user_data: userData, 
 
 iv: iv 
 
 }, 
 
 success: function (res) { 
 
 // On the server, parse and generate your own account verification information   
 
 var user = res.data.user 
 
 var token = res.data.token 
 
 // And it can also be stored in local storage for next time you open it   
 
 wx.setStorage({ 
 
 key: 'my_token' , 
 
 data: token 
 
 }) 
 
 } 
 
 }) 
 
 } 
 
 }) 
 
 } 
 
 }); 

How is the interface presented?

When the mini program was first released, many people started to exclaim that the era of Html5 was coming, because the mini program used the Html/CSS/Javascript technology stack of Html5 in the interface layer. But soon, as smart programmers got a deeper understanding of the mini program, they found that the Html/CSS/Javascript in the mini program was completely different from that in Html5, and the difference was basically the same as the difference between Java and Javscript.

In mini programs, the equivalent of Html is **WXML**, which retains only the concept of Html, while the traditional `<div>` `<a>` tags are completely abandoned. Similar to Facebook's React, mini programs have introduced their own Html tags. Unlike semantic tags such as `<article>` `<section>`, the tags in mini programs are more like **components** (or controls) in traditional client development. Each component has its own function and usage. For example: if you need to display a picture, you can only use the `<image>` tag, and other tags cannot carry it. If you need to provide optional text, you can only use the `<text>` tag, and so on. The biggest problem with this approach is that traditional Html pages cannot be presented in mini programs (and mini programs just happen to not provide client controls like Web View).

For example, a large number of content websites store their articles as an Html fragment, which cannot be directly presented in the mini program. If display is required, one idea is to build an intermediate service to translate Html into an intermediate format data that is simpler and easier to render, and then convert the intermediate format data into the mini program's tags for presentation on the mini program side. When we were working on [Qingmang Life](http://s.qingmang.mobi/10c), we happened to design and implement an escape service that converts any Html page into an intermediate format (internal name is RAML), solving the problem of presenting content-based Html pages on mini programs.

(Present Html content page in the applet)

Compared with Html, the ** WXSS ** of the mini program can be said to have relatively completely retained the characteristics of CSS, which is quite unexpected. The biggest difference in semantics of WXSS is that it supports the relative size unit `rpx`, and every 750rpx is equivalent to the screen width of the current device. The introduction of this relative size unit makes the complicated screen size adaptation much simpler. Another difference from CSS is that it is more like the traditional control style usage, and does not support as many selectors as CSS3. In use, it is more often used as one control and one class.

Although the mini program supports Javascript of ES6 standard, the window-level Javascript is completely abandoned in the mini program. Developers cannot use Javascript to call window and document objects to modify interface elements to complete logic. Javascript in the mini program actually directly corresponds to the usage of node.js, which is used to complete background business logic instead of directly controlling interaction. This design of the mini program allows it to use virtual dom to render the interface, making it possible to optimize the performance when updating interface data, but the price paid is that the glue of window-level Javascript is missing, making the development of many functions extremely rigid and complicated.

How is the interaction transmitted?

The so-called interaction transmission refers to the way in which the platform framework informs the business layer when the user interacts with the interface, and presents the processed changes back to the interactive interface. If you regard the page drawn by WXSS + WXML as the "front end" and the business logic written in Javascript as the "back end", you will find that the front-end and back-end interaction of the mini program is particularly similar to the Web 1.0 model. The front end encapsulates the interactive behavior into an **event** and sends it to the back end. After the back end completes the processing, it transmits the data back to the front end through the **setData** method.

(Interactive conduction of mini programs)

The events provided by the mini program include basic events such as single click, long press, touch, slide, etc. For controls such as video players, there are also listening for play, pause, etc. These events are relatively basic, without more advanced gesture, multi-touch and other related events, but they are still enough for developers to understand the user's input in detail and respond accordingly.

The only way for the mini program to respond to the interface is to update the data on the interface through the setData API in the Page. The mini program will compare the changes in data between two calls to decide which part of the interactive interface needs to be updated.

For example, suppose a developer needs to make a sliding page switching effect. How to implement it in a mini program? First, introduce variable data into the rendering page:

<view class="page" id="current-page"

style="left:{{distance}}rpx;"

bindtouchstart="movePage" bindtouchcancel="movePage"

bindtouchmove="movePage" bindtouchend="movePage">

</view>

As you can see, `distance` is a template parameter, and its initial value is 0, which indicates the distance moved. The event is returned by binding the Javascript method through functions such as **bindtouchstart**.

 movePage: function (event) { 
 
 var status = { 
 
 needUpdate: false , 
 
 distance: 0 
 
 } 
 
 // Handle various events, calculate whether to refresh, and the direction of movement   
 
 if ( "touchstart" === event.type) { 
 
 // Start calculating movement   
 
 ... 
 
 } else   if ( "touchend" === event.type) { 
 
 // Determine whether the moving distance is sufficient.   
 
 ... 
 
 } else   if ( "touchcancel" === event.type) { 
 
 // It's okay to be interrupted.   
 
 ... 
 
 } else   if ( "touchmove" === event.type) { 
 
 // Calculate the moving distance   
 
 ... 
 
 } 
 
 // Update the interface based on the distance moved   
 
 if (status.needUpdate) { 
 
 this .setData({ 
 
 distance: status.distance 
 
 }) 
 
 } 
 
 } 

On the Javascript side, the event is captured, the offset is calculated, and the new offset is sent to the front-end interface.

From this we can see that the interaction mode of the mini program is a typical one-way mode. The front end returns events and data is pushed to the front end in a one-way manner, rather than being notified through methods such as "variables" and "states". In this mode, developers often cannot control interface changes very accurately. The entire core depends on the mini program's diff calculation of two data changes, which will ultimately affect the performance of the entire interaction.

Features of Mini Program Development Model

At this point, we can summarize some of the characteristics of mini program development. Overall, mini programs use the HTML5 technology stack and follow the traditional client development model, which is similar to platforms such as React and can be regarded as a new branch of HTMLl5.

From the design perspective, mini programs have a lot of "restrictions". The biggest restriction is that developers cannot directly control the interface through programming languages ​​such as Javascript, but can only achieve it indirectly through data-driven. This is beneficial for people who lack development experience because it lowers the threshold for understanding, but for complex applications, this model is relatively rigid to develop, and often requires multiple modifications for one change, which increases the cost of understanding the code.

Pitfalls of developing mini programs

The days of developing mini programs are also a journey of stepping into pitfalls. In brief summary, the pitfalls in mini programs probably come from the following aspects:

Compatibility with the Web . The applet introduced Html/CSS as a technology stack and customized it based on it. Many problems in development come from "customization" because you don't know which part is customized and which part is inherited. For example, you use a CSS syntax and find that it does not work, or the effect is different from that in the browser, so you can only change the writing method. As a result, it is very likely that you will continue to find that this new writing method may not work properly, so you can only continue to try, and this repetition may consume a lot of time.

The development environment is unstable . The development of mini programs is based on an IDE made by WeChat, but at present, the stability and usability of IDE are very poor. Bugs often appear. You think your program is wrong, but in fact, it is a bug in the IDE. Restart the IDE and everything will be solved. Therefore, when you encounter some abnormalities when developing mini programs in the future, restarting the IDE first and then seeing if the problem still exists may be a more time-saving way.

Lack of real-device debugging environment . The runtime of the mini program is actually WeChat, and WeChat provides almost no real-device debugging tools for you (it cannot be said that there are none at all, there is a log box that can only be read with eyes wide open on a real device). The program you debugged in the simulator may not run as expected on the real device. For example, we have encountered problems such as white screen, disordered position, incorrect animation effects on real devices, and it still cannot run on Android. This is quite a nightmare for slightly complex programs. If you want to make some fine-grained adjustments and optimizations, you can basically only rely on guesswork.

Closed source and lack of learning materials . The applet is closed source as a whole (although the simulator and IDE parts can be seen through decompilation), and there is a lack of sufficient learning materials. If you encounter problems such as how to use the controls and why they are used incorrectly, you can only solve them by repeated trials, which also takes a lot of time.

***Introduce "Qingmang Mini Program+". "Qingmang Mini Program+" is a mini program solution proposed by the Qingmang team. It will help content entrepreneurs build their own WeChat mini programs for free. In addition to content publishing, the mini programs they create will also have special features such as comments, notes, and paid reading. Qingmang Mini Program+ does not intend to create a new content platform, but to convert the existing self-media accounts of content entrepreneurs into WeChat mini programs. As long as content entrepreneurs update their self-media as usual, these contents can be automatically updated to the mini program.

In short, as a new development platform, WeChat Mini Programs are not perfect in terms of their own stability and supporting tool chain. For early developers, it requires extra effort to try and explore, but this may be the value and cost of a new platform.