When it comes to forms, they generally include: data collection, inspection, interface interaction for illegal input, and data delivery. This article gives a brief introduction to these parts and the common processing methods used in development.

Data collection

Normally we listen for the event of the form submit button, and the event handler collects the form data. There are probably several collection methods:

  • Browser automatic collection: giveformElement setactionThe receiving address of the form data so that the data is automatically collected and transmitted after the click is submitted. This method is simple and convenient, but the disadvantage is that it cannot be customized effectively and many scenarios are limited.
  • FormData constructor: Passes the form element to the FormData constructornew FormData(formElement)Pass the formData data to the server.
  • Custom data format: by getting each fieldvalue, free assembly.

We usually use the last one because of the degree of freedom.

Check of data

Data checking, also known as form verification, avoids invalid transmission by setting rules for form fields to avoid sending invalid forms to the server.

There are many ways to check, the most common of which is to write regular expressions to check input characters.

A single field may have more than one check condition.

Sometimes a field may require a union of multiple conditions that is difficult to check by writing a regular expression (which can make the re long and tedious, increasing the probability of errors). It is also a good idea to check for simple characters, such as checking that the mailbox input must contain the @ sign: emailValue.indexof (“@”) > -1

Sometimes a field check depends on the value of another field, and we need to do some encapsulation.

Finally, you need to record the results of each field check and which rules failed.

Interface prompt

With the results of the form check, we need to tell the user what the results are and what the rules are for those fields. To help him enter the correct value.

In this step, there are several details:

  • Timing of prompt
  • Hints on malleable form of text: fixed or automatically spread

It’s not so much a development detail as a product detail.

From the user’s point of view, no one likes to be disturbed for no reason. Take the regular login program as an example: when a user operates or enters a username field, there should be no prompt for the validity of the password. The state of a field is touched if it has been entered or manipulated.

The benefits of fixed prompt text minimize the visual jump of elements, but the interface can look looser,elementUIThis is done in a fixed way, by enlarging form elements and shrinking prompt text to counteract looseness:

The opposite is true for automatic unbunching.

I personally prefer the auto-open prompt question, which is a bit more compact and design-friendly.

Transmission of data

Data transfer is actually relatively simple, usually via Ajax or FETCH. I personally prefer Ajax