Some issues and solutions in the process of mini-program development.

Preface

Recently, I completed a mini-program for content distribution. The core functionality includes editing, uploading, and commenting on articles (plus WeChat Official Account). The framework used for this project is mpvue and vant-weapp. I chose this framework because it is the one I am most familiar with. The main reason for this choice is that the project was quite rushed. Although I had previously studied uniapp, I had never used it to write a project. It would take time to learn and troubleshoot, so I ultimately decided to use this technology framework as the foundation for this mini-program. Since I had never worked on this type of mini-program before, I encountered some issues with uncommon WeChat components.

Troubleshooting Record

editor component

Editing articles is one of the core functionalities. After discussing with the backend team, we decided on the simplest solution, which is to store the articles as rich text. The rich-text component can be used to display the articles in the mini-program, and there are no issues with the backend management system as well since the data is stored as text in the database. We used tinymce for rich text editing in the backend management system, but for the mini-program, I could only find the editor component.

The issues encountered with the editor component are as follows:

• The editor component does not support scrolling, and the cursor can only be moved within the input box.
• When the editor component reaches the bottom and the user presses enter, the cursor moves to the bottom and becomes invisible. It only becomes visible when content is entered.
• The editor component provides many APIs, but many functionalities need to be implemented manually. You can refer to this article by a fellow developer for a custom rich text editor implementation: Rich Text Editor Encapsulation.
• Although the editor component has comprehensive input functionalities, such as uploading images and resizing, the user experience is poor on actual devices and requires a learning curve. The focus of the component conflicts with custom key events, causing the keyboard to keep popping up.

Due to these issues, we ended up removing most of the functionalities of the editor component and only kept the basic text editing functionality. More advanced styling editing was left to the web backend. Here are a few improvement ideas I have, which can be considered based on the project's future requirements.

• Replace the editor component with a textarea and image upload functionality to generate rich text content for submission to the backend. Users can choose to add paragraphs or images, reducing the operation cost. The drawback is that custom styling is not supported, but having a unified style can help maintain consistency in the mini-program's display. I believe this is the most cost-effective approach until we have the capability to achieve the same level of technical sophistication as WeChat Official Account editing.
• When editing, navigate to a page that only contains the editor component and remove all other components to focus on resolving the keyboard issues. This solution requires further research and carries some risks.
• Develop a custom virtual keyboard to incorporate custom key events. This could be the ultimate solution. (WeChat Official Account can take inspiration from this)
• Wait for the official fix for the bugs (which may be indefinitely delayed).

Different display on iOS and Android

This issue has been around for a while. In fact, one of the innovations of WeChat mini-programs is the ability to run on both iOS and Android devices with the same user experience (although some special models have their own unique bugs, like the iPhone X). But let's be honest, if there's a pit, we'll wait for someone to fall into it, and if there's a bug, we'll have to fix it.

iOS has different formatting requirements for the new Date() method in JavaScript compared to Android.
This issue was discovered in a previous mini-program, and I want to mention it again this time. Generally, the date format stored in the backend is yyyy-MM-dd, and the new Date() method in JavaScript can correctly parse this format. However, iOS is different. Its JavaScript only supports parsing the date format yyyy/MM/dd. Since ordinary Android phones also support parsing this format, the date string received from the backend needs to be uniformly processed:

const dateString = "2020-12-14 00:00:00";
const date = new Date(dateString.replace(/-/g, "/"));

For those who find this troublesome, you can request (threaten) the backend team to perform unified data processing. In general, the backend (in this case, Java) can achieve this through annotations in fastjson (one by one), or by configuring a unified interceptor to handle date data formats (these configurations are usually used for converting long to string, as JavaScript's number type has precision loss when compared to Java's long type).

Issue with losing focus on input in iOS (possible bug)
In general form design, it usually involves input and picker. In the iOS real machine experience, when you first click on the input box and then click on the picker (native picker or vant component picker are the same), the keyboard does not automatically close.
The solution here is to call a WeChat API wx.hideKeyboard(), but the downside is that it cannot be displayed properly in the developer tool.

    popup(showPicker) {
      // console.log(this[showPicker])
      // this[showPicker] = true
      // 解决ios键盘不收起的问题,开发者工具时可以注掉
      wx.hideKeyboard({
        complete: res => {
          this[showPicker] = true
        }
      })
    }

The behavior of position: fixed; in iOS with the editor component is different from Android
For specific information, you can refer to this bug report.
Currently, it is only a poor user experience and has not been fixed. You can try the approach mentioned in the second floor comment.

In iOS, you can only manually set the bottom distance after obtaining the keyboard height.

It's worth a try.

Reflection and Consideration

This project is not considered large in scale, with a total of 25 pages, of which only two pages are similar (one tabbar page and one regular page, where passing parameters in the tabbar page is not ideal). Many manuscript list pages are reused, which works well. Due to the tight schedule of the project, no business components were developed, and some similar elements (such as the manuscript item in the list) were not reused, requiring synchronous modification of the UI. Fortunately, there are not many pages to take care of.
Looking back at the entire development process, there are a few areas that still need improvement:

• Design several commonly used page templates (list, detail, info) and organize several commonly used methods (pagination, input, page navigation) to greatly accelerate development speed.
• When using UI components, it may be necessary to fork a customized version and develop it accordingly.
• Documentation is needed for frontend-backend interaction, otherwise, maintenance in the later stage can be very troublesome.
• Module differentiation can be achieved through naming, making it easier to migrate modules when encountering similar business requirements in the future.
• Learn modular development of style classes to facilitate unified modification.
• Use ScreenToGif software to record dynamic effects, which facilitates reflection and consideration for learning and growth (and maybe write a blog post).

This post is translated using ChatGPT, please feedback if any omissions.