va.js—The writing process of Vue form validation plug-in

Foreword

Some time ago, the boss set up the Vue development environment, so we happily came to Vue from JQ. During this period, I was not happy with the form verification. When I saw the plug-in chapter of Vue, I felt that I could write one, so I started writing a form verification plug-in va.js. Of course why not find a plug-in? vue-validator.

I thought about it. One is that form verification is a highly customized thing. In order to take into account the needs of various companies, this kind of plug-in found online adds a lot of functions, which we don’t need. It turns out that vue-validator is 50kb, and the va.js I wrote is only 6kb.

Another thing is that I really think the API of vue-validator is very long. It’s always v-validate:username="['required']", such a long list, and the call I designed is probably like - v-va :Money

Of course, this article only shows how to write a vue form validation plug-in that meets the needs of your company. The following introduces the ideas.

1. The composition of the form validation module

Any form validation module is composed of configuration - verification - error reporting - value collection.

Configuration: Configuration rules and configuration error reporting, as well as priority

Verification: There is verification in the change event, verification when the submit button is clicked, and of course there is also verification in the input event value

Error reporting: The error reporting method is generally points, the error text has a template, and also has a customized

value: Return the verified data to the developer for a call

The following is the request my boss made to me for the company project

Centralized management verification rules and error reporting templates.

The error reporting time is optional

The verified data has been packaged into objects and can be used directly

to allow each page to override the rules, customize the error reporting information, and allow ajax to obtain the data, and then The rules are supplemented

I asked curiously, why is it like this? Then the boss answered me one by one:

The advantage of centralized management rules and error reporting templates is that the rules can be used globally and can be changed once and for all. The boss told me that the regular nickname alone was changed three times. If these regular rules are written on each page, o(￣ヘ￣o#) hum, you will have to change N pages

PC and mobile processes are different. Many verifications on PC must be done in the change event or input event. Verification and error reporting, while mobile generally requires going to the submit button for verification. So be prepared when writing a plug-in. Then, the UI used for error reporting must be able to support the layer plug-in we are using now. Of course, the error UI may change in the future, so you understand.

Of course, in the jq era, our public form verification can complete the verification and collect all the data into one object. In this way, there is no need to get the value when using ajax. This plug-in of yours is going to achieve this effect

It turns out that jq’s public script, regular expressions and error reporting are all concentrated in one place, which is very convenient in many places. But it is not flexible enough when some pages need to be changed. Rules like RealName were first configured for a certain page, using the field names on the backend interface. On another payment page, the field name on the back-end interface has been changed to PayUser, but the regular expression is still RealName. It turns out that we need to overwrite RealName. This is not convenient and looks good. The other one, the payment amount, has maximum and minimum limits, which need to be obtained from the backend. You also need to consider this situation. It is necessary to have some flexibility on each page to modify rules, customize error reporting, etc.

After listening to it, I roughly understood it. It turned out that the jq form verification I wrote before had so many uncomfortable points. -_-|||Next, let’s take a look at the good things vue has given me. Let me write

Second, how to write a Vue plug-in

I am a Vue novice, why did I start writing a Vue plug-in? That’s because when I was thinking of a solution, I flipped through the Vue documentation and came here

these things. When I finished writing va.js, I felt that what you wrote was really clear.

Actually, I want to write a command to complete form verification. It turns out that there may be 2-3 instructions, and some methods need to be defined on Vue.prototype so that the rules can be expanded within each sub-instance. So the boss said, this is equivalent to a plug-in. This makes me feel like a whale.

va.js mainly uses Vue commands

These things, when I finished writing va.js, I felt that what you wrote was really clear.

Actually, I want to write a command to complete the form verification. It turns out that there may be 2-3 instructions, and some methods need to be defined on Vue.prototype so that the rules can be expanded within each sub-instance. So the boss said, this is equivalent to a plug-in. This makes me feel like a whale.

va.js mainly uses Vue instructions

Vue documentation is really written carefully, but let me add one more thing
vnode.context is an instance of Vue
When we are doing projects, we often There are N sub-components hanging on a root component, and N sub-components may be hung on the sub-components. The instance obtained by vnode.context is the instance of the component bound to the instruction. This is quite useful. You can do a lot of things

Of course you also use some Vue.prototype

Vue.prototype.$method is the method that can be called on each component. It can be called using this.$method inside the component