Mpvue development pit record

First, explain why mpvue is used. This project is mall development, requiring the online small program and wechat public number at the same time. In order to facilitate later maintenance and iteration, a set of code is planned to be shared by multiple platforms. Use Webpack to differentiate code that cannot be shared during packaging (the implementation is done by the team leader). In this record of the development process encountered pit (mostly mpvue/ small program encountered pit), and you encourage.

1. Mpvue large array update

① Specific tasks

In the menu list, it is necessary to list all the dishes (ranging from 20 to 1000) and provide adding and subtracting operations. To optimize the display have lazy loading (scroll to where to load the current display column of dishes).

② Specific problems

The idea is simple: iterate through the array with V-for and dynamically modify the array based on the distance returned by the scrolling event. It is very smooth to use in the Web without other problems, but in the small program, the use of less than 20 courses is ok, 20 to 80 courses are stuck, 80 to 120 courses are seriously stuck, when 230 courses, the small program will be directly blocked probability exit. The phone I was using was Xiaomi Mix2S. Normally, full blood Snapdragon 845 can’t carry this small program, so don’t expect the mid and low-end models to be able to use it smoothly.

(3) analysis

The stall including the stall occurs during the scroll of the menu component, namely the scroll view. It is necessary to figure out what happens during this scroll. The first is to trigger the scroll, and then calculate the new dish information to be rendered in the new area according to the height of the scroll event (to replace the previous blank content or placeholder content). The new menu information is then updated into the long array, and when the page is rendered, the user sees the new menu information in one scroll. So the problem basically lies in the four aspects of scrolling trigger, new dishes calculation, data update and page rendering.

④ Solutions

Scroll trigger:

The scroll view of the applet seems to have throttled the scroll event itself. I need to make the scroll only trigger on the last time, so I’m going to take a shake off of the scroll event.

let first = true;
debounce(firstfn, endfn, interval) {
	if (first) firstfn();
	first = false;
	if (timer) clearTimeout(timer);
	timer = setTimeout(function () {
		endfn();
		first = true;
	}, interval);
}
Copy the code

For some reason, vue’s throttling and anti-shaking won’t work. In this way, the scroll event will only be triggered on the first and last time of the scroll, reducing the number of scroll requests.

Data update

The way long arrays are handled in MPVue may not be what we understand. In MPvue, if you modify a value in an array, instead of applying this.setData to the current value, you rewrite the entire array with this.setData. That is, any change to the array will cause the entire array to be rerendered on the page. The final solution is to ditch mpVUE. . Of course, it is not completely abandoned, the dish list (mainly the function of changing the placeholder information to real dish information) written by small program language, made into small program components re-introduced to the MPVue code.

// productList is a long array for presentation
// realList is all real dish data
let data = {}
data["productList[" + num + "]"] = Object.assign(data,realList[num])
this.setData(data)
Copy the code

This way you can modify only one value of an array in a small program without reassigning the entire array.

The contents of the loop contain components

Rewrite the plus and minus components inside the loop as applets.

conclusion

In short, component nesting is reduced and large array value handling is written in a small programming language.

Ps: There seems to be an official optimization for large array assignment in mpvue (1.0.18)

2. Text jitter in the input box

First of all, this problem has been solved and optimized in the MPvue version (1.0.18). Although it is still a bit shaky in Focus, it is much better. So my solution is to go back to the previous version.

In fact, the main cause of text jitter is the use of V-Model. The best way to do this is to ditch the V-model and replace it with :value and @input.

<input :value="iptValue" @input="input" />
Copy the code

If you insist on v-models (for example, the project needs to be compatible with public numbers and applets), you can use lazy modifiers to solve the problem. Although there is a flash after blur, it is not a big problem when typing.

<input v-model.lazy="iptValue" />
Copy the code

3. Mpvue performance optimization

Back to the above, although the scrolling is smooth, there is a big delay in adding or subtracting dishes — about half a second to three seconds after clicking the “+” before the dishes are added to the cart and the quantity changes — which is very uncomfortable. Struggling to find the reason or group leader found the problem (big guy beer ah…) When the value in mpVue changes, all values in the page are updated, including the values of data,props, and computed non-objects for all components in the page. After changing one value during the test, all value updates were triggered 14 times. So the solution is to reduce the use of data,props, and computed.

computed

Give it up if you can. Computed and Watch do not exist in small programs. Use in small amounts if required.

props

For an incoming component that doesn’t need to change too much to merge into an object, MPvue has a separate optimization for the object and doesn’t go into the updated.

data

Only values that need to be rendered on the page or passed to other components are placed in data; values that do not need to be rendered are placed outside data

. let num =0; // No rendering required
export default {
	data(){
		return {
			show:true // Need to render.Copy the code

watch

Watch is a bit metaphysical for me. I found that the value transfer between components after using Watch would be relatively slow on ios (400ms to 2300ms). So don’t use it if you can, especially watch’s deep monitoring. If you want to use depth listening, use a different, simpler value (such as Boolean) instead.

4. Pull-up loading and pull-down refreshing of small programs

There are two options, the first is to use the onPullDownRefresh and onReachBottom provided by the applet, but these two are page events and are not applicable if you need to pull down refresh and pull up load within the area. The second is hand-written pull-up load and pull-down refresh, without an API we just build our own wheels. But most of them are made with CSS3 animation, CSS3 animation is not smooth in the small program, so… In the final analysis, we should set up a good product and convince TA

5. Code differences between small programs and public numbers (part)

Because the current project is the public number and small program to share a set of code, but some effects or API gap, list the relatively large gap encountered.

How to obtain user information

The small program can obtain user information (including avatar, nickname, gender, etc.) through the open-data component and wx.getUserInfo public account now can not obtain user information through JSSDK, can only rely on the background to obtain user information to wechat

mounted,onShow

This is the difference between applets and the Web, where pages are destroyed before they advance, and pages are “frozen” before they advance. Mounted is triggered by web, and onShow is triggered by applets. Life cycle functions for writing applets on the Web do not report errors and do not trigger. I’ll talk about the current page when I go backwards in the next question.

6. Mpvue data cache problem

After A small program compiled by MPvue goes from page A to page B, from page B back to page A, and from page A to page B again, the last data remains. In fact, the list page will go to a different detail page, the second detail page will also carry the previous data. In my opinion, data caching is a double-edged sword — methods that need to be executed every time they get to the page now only need to be executed the first time (such as some values that calculate the height and distance for display). But re-entering the page with the previous data (such as details) is not a good look. The main reason is that the page gets destroyed (onUnload) when the applet goes back, but the values stored in mpVue still exist and are not destroyed. So onUnload can clear mpVue data once.

onUnload(){
	Object.assign(this.$data, this.$options.data());
}
Copy the code

7. Top sucking effect of small program

There are only two ways I can think of doing this.

Page scroll detection

Use onPageScroll to check the scrolling height of the page and add position:fixed to the element when it reaches the specified height. This is possible, but with a significant delay (similar to the McDonald’s order sidebar)

sticky

Use CSS sticky positioning to achieve top sucking, which is not as good as lag. But the biggest problem is…. The compatibility is not good. The basic small program library does not support sticky in 2.3.2, but supports some sticky in 2.4.2. My own test results show that IOS is basically supported (only iphone5,iphone6 is under IOS 12), android platform is not sure. I use sticky positioning in line with the mentality of using it and not affecting operation. I also don’t know which models don’t support….

8. The problem of IOS

IOS, most of the problems I can’t solve are due to IOS, just to name a few… Just once, another phone of the same model with the same system is fine, then let the component delay creation is no problem.

Popup offset for vant on IOS10

I see that the latest version of the official document has solved the popup offset problem in IOS8, but I still have the offset problem in IOS10.

IOS applet pages have pull-up and pull-down drawings

Test results: enablePullDownRefresh: false invalid disableScroll: true, but is in itself a list page, could not disable the scroll. No better way has been found…

The IOS applets are slow to transmit values

That’s what we saw in the first problem. The transfer of values (long arrays) from the Vue component I wrote in MPvue to the applets component I wrote in applets took about 1400ms to 2300ms on IOS, which is way too long. After that, I simplified the contents of the array, and passed the short array first and then the long array to improve the user experience. The optimized value transfer also took about 1000ms to 1500ms. There is no complete solution to…

9. To summarize

The first time to write mpvue project, is also the first time to contact small program project. I finished the basic process of the project in less than a month, but I was still not capable enough. “Burrow” still not successful, code… It needs to be optimized