What is the most difficult public business to implement in WeChat mini programs? It should be form verification. This article mainly introduces how the WeChat applet implements the form verification function. It has certain reference value. Interested friends can refer to
Mini Program SDK version 1.4
Difficulties in form verification
If you want to ask what is the most difficult public business to implement in WeChat mini programs? It should be form verification, nothing else. The reasons are as follows:
The number of form components reaches 11, ranking first among all types of components. Fortunately, not all of them need to be verified.
The operation methods of these components are diverse, which can be divided into sliding, (multi-line) input, clicking, and clicking + sliding.
Even if it is the same component, there will be different verification rules due to different business scenarios.
What’s even more troublesome is that these components are often linked or associated with each other for verification.
…
However, as a non-simple static page, there is a small program with a lot of user interaction, and form verification is a very common function: login, registration, new addition, editing…
In short: Diversity of form components
Try componentization
If you pay attention to the front-end development trend in recent years, you will definitely think of "componentization" to achieve:
The views, styles, and validation logic of each form component are encapsulated into separate business components and then called directly.
But things don’t seem to be that simple.
If we consider abstracting n native components, adding n verification rules, and then multiplying by n (full arrangement) of the relationship between components, the complexity will reach at least n³.
And each component’s verification failure or success must notify the parent component so that the error message can be displayed or the next step can be performed.
Not only does this not solve the problem, but it also makes these public form components too complex and confusingly coupled.
Try non-componentization
Since the original idea doesn’t work, let’s go back to the starting point and see what our core needs to be abstracted .
It’s nothing more than two things: the element style of the view layer and the verification rules of the logic layer.
As mentioned above, encapsulating native form components will greatly increase the complexity. Simply abandon it, and the complexity can be reduced to n² in an instant.
But at the same time, we must maintain a unified style, which is what we often call consistent style.
For example, how high should the input box be, how to display error prompts, font size and color...etc.
This is easy to do. We write the style class into a public style file form.wxss, and then import it when needed, or even import it globally.
// form.wxss .form { display: block; font-size: 28rpx; position: relative; } .form-line { background-color: #fff; border-bottom: 1px solid #e5e5e5; font-size: 34rpx; height: 96rpx; line-height: 96rpx; display: flex; padding: 0 31rpx; } .form-title { box-sizing: border-box; background-color: #efefef; color: #838383; font-size: 28rpx; padding: 31rpx; min-height: 90rpx; } ...
// xxx.wxml
The ideal state of verification rules is extensible and configurable.
Scalable. As your business grows, you can add new verification rules without modifying existing rules.
Configurable. Different single or multiple validation rules can be configured individually for each form component.
How to make it definable? Just use a unified form. For example:
/* 统一的格式: [规则名]: { rule: [校验方式] msg: [错误信息] } */ const validators = { // 简单的校验用正则 required: { rule: /.+/, msg: '必填项不能为空' }, // 复杂的校验用函数 same: { rule (val='', sVal='') { return val===this.data[sVal] }, msg: '密码不一致' } ... }
The configured rules must be on the native form component, and the value of the component can only be obtained through the event object.
If you directly bind the event for verification, it will prevent the parent page from obtaining the value, so it is best to pass the value by the parent page binding event, and pass in the event object and execution environment for processing:
/* 校验函数部分代码 e 事件对象 context 页面对象函数执行的上下文环境 */ let validate = (e, context) => { // 从事件对象中获取组件的值 let value = (e.detail.value || '').trim() // 从事件中获取校验规则名称 let validator = e.currentTarget.dataset.validator ? e.currentTarget.dataset.validator .split(',') : [] // 遍历规则进行校验 for (let i = 0; i < validator.length; i++) { let ruleName = validator[i].split('=')[0] let ruleValue = validator[i].split('=')[1] let rule = validators[ruleName].rule || /.*/ if ('function' === typeof rule) { rule.call(context, value, ruleValue) ? '' : validators[ruleName].msg } else { rule.test(value) ? '' : validators[ruleName].msg } } ... }
// 部分代码示例 // page.wxml// page.js valid(e) { this.setData({ [e.currentTarget.dataset.name]: e.detail.value }) validate(e, this) }
The above is the detailed content of Example of implementation of form verification function in WeChat applet. For more information, please follow other related articles on the PHP Chinese website!