WeChat applet development chapter: pitfall record

Recently, I participated in the development of the company's first mini program. The development experience is basically similar to the hybrid development based on webview. It can call the official powerful API, but there are also some pitfalls or things that I am not used to. This article records some problems in the development process from the perspective of practicality:

1. Confused style priorities

When using the button component, I found that setting the width in the class does not take effect. Here is the code:

.my-button{
 width: 140rpx;
 height: 60rpx;
 line-height: 60rpx;
 padding: 0;
}

After checking with WeChat debugging tools, we found that the style priority of the user agent is higher than the style class we wrote ourselves. This is basically impossible in the browser.

The solution is actually quite simple. Just add the suffix !important to width or style="width:140rpx". Let's take a look at the effect after modification:

After adding !important, the actual effect of the width has actually met our expectations, but the WeChat debugging tool still shows that the user agent style takes precedence. This should be considered a bug in the debugging tool.

2. Ordinary UI component encapsulation, cumbersome parameter definition

Generally, basic components in UI visual drafts, such as buttons, have specific styles: for example, background color/font. Use the Component function of the mini program to encapsulate it into a component, write the default style and receive the class passed in from the outside to facilitate subsequent development.

React has a writing method called <tag {...props}></tag>, which means that the component receives props without processing them and just passes them on to the next component. However, Mini Programs do not support this writing method (searching hard has yielded no results, and the official documentation does not explain it either).

This means that we need to list all the parameters supported by the button component in properties:

properties:
  classes: {
   type: String,
   value: '',
  },
  type: {
   type: String,
   value: 'default',
  },
  plain:
   type: Boolean,
   value: false,
  },
  size: {
   type: String,
   value: 'default',
  },
  ......
 },

3. The global style selector * is disabled

*{
 box-sizing: border-box;
}

The above code will report an error when compiling because the applet prohibits this type of selector. A bold guess for the specific reason is: this type of selector with a relatively wide scope conflicts with the style isolation of custom components? ?

So how do you add global common styles to the mini program? It seems that I can only write all the used tags manually. Fortunately, there are ready-made codes on the Internet that can be pasted:

view,scroll-view,swiper,swiper-item,movable-area,movable-view,cover-view,cover-image,icon,text,rich-text,progress,button,checkbox-group,checkbox,form,input,label,picker,picker-view,radio-group,radio,slider,switch,textarea,navigator,functional-page-navigator,image,video,camera,live-player,live-pusher,map,canvas,open-data,web-view,ad{
 box-sizing: border-box;
}

4. Custom component, bind:tap is called twice

When encapsulating basic components, such as buttons, the following should be avoided:

onTap(e) {
 if (!this.data.disabled && !this.data.loading) {
  this.triggerEvent('tap', e.detail)
 }
},

<button bindtap="onTap"></button>

The component encapsulated in this way will trigger two tap events, one by the mini program itself and one by triggerEvent.

You can change to an event type that is not built into the applet, such as click:

onTap(e) {
 if (!this.data.disabled && !this.data.loading) {
  this.triggerEvent('click', e.detail)
 }
},

Preventing the tap event from bubbling can also solve the problem:

<button catchtap="onTap"></button>

5. Use Boolean() for type conversion in wxml

For example, in a component, listen for a String type parameter. If it is not empty, the text label is displayed, otherwise it is not displayed:

// player.wxml
<text class="text1" wx:if="{{ Boolean(leftText) }}">{{ leftText }}</text>

// index.wxml
<player leftText="Read"></player>

In this way, the leftText field is obviously passed, but the text label is still not displayed. When the other way is written:

// player.wxml
<text class="text1" wx:if="{{ leftText }}">{{ leftText }}</text>

This is correct and meets our expectations.

Isn’t it amazing?

6. After InnerAudioContext calls the seek method, the onTimeUpdate callback becomes invalid

InnerAudioContext is used to play audio. Pass the onTimeUpdate callback to it to get the current playback progress.

However, when the seek method is called to jump to the specified position for playback, onTimeUpdate is no longer called.

Many people in the mini program community have raised this issue. After about a year and a half, the WeChat team has not fixed it yet. We can only use a compromise solution temporarily. The solution is actually very simple:

progressOnChange(e) {
 if (this.properties.src && this.data.innerAudioContext) {
  const innerAudioContext = this.data.innerAudioContext;
  innerAudioContext.pause();
  innerAudioContext.seek(innerAudioContext.duration * e.detail.value / 100);
  setTimeout(() => {
   innerAudioContext.play();
  }, 500);
 }
},

First pause the playback, then execute the seek method, and then set a delay of about 500ms to call the play method.

7. Timing of getting duration in InnerAudioContext

I wanted to get the duration before the audio is played, but it is not possible. The statements on the Internet about calling onPlay and onCanplay are not very reliable. One solution is this:

innerAudioContext.onCanplay(() => {
 setTimeout(() => {
  this.setData({
   durationStr: secondToTimeStr(innerAudioContext.duration) || '--:--',
  });
 }, 500);
});

Not to mention how many milliseconds are appropriate to set setTimeout, it is invalid on a real machine.

So it’s better to use onTimeUpdate:

innerAudioContext.onTimeUpdate(() => {
 this.setData({
  durationStr: secondToTimeStr(innerAudioContext.duration) || '--:--'
 })
});

If you think that calculating every onTimeUpdate is too performance-intensive, you can implement it yourself and only calculate it once.

8. Set the page background color

There is a backgroundColor field in the json file of the current page, but it is invalid after setting. Later I found that this field does not represent the background color of the visible area, but the background color of the window when the page is pulled down.

If you need to set the page background color, you can set it through the style of the page tag:

page{
 background: #f9fafb;
}

Summarize

This is the end of this article about the pitfalls in WeChat Mini Program development. For more relevant content on WeChat Mini Program development pitfalls, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope you will support 123WORDPRESS.COM in the future!