In most cases, we recommend using controlled components to process form data. In a controlled component, form data is managed by the React component. Another alternative is to use uncontrolled components, where the form data is handed over to DOM nodes for processing.

Above is the React website for controlled components and uncontrolled components of an explanation, university graduate from college, see this section, some really hard to accept, in my opinion, since has chosen to use the React, it should be totally controlled components, the use of why developers will have directly using the DOM node development of uncontrolled components. In VUE at the time, there was no such setting. At the same time, I was developing Sass website, because the development of PC side website always requires instant verification (instant user interaction, so that users will not be too frustrated after filling in the complete data and then prompting errors).

For now, though, uncontrolled components are a good design for React.

Distinction and selection between uncontrolled and controlled components

Uncontrolled input is like traditional HTML form input:

class Form extends Component {
  /** Get data when commit */  
  handleSubmitClick = (a)= > {
    const name = this._name.value;
    // Test data prompt then
  }
  render() {
    return  (
      <div>
        <input type="text" ref={input= > this._name = input} />
        <button onClick={this.handleSubmitClick}>Sign up</button>
      </div>); }}Copy the code

We only get the values in the DOM data when other events are triggered, such as clicking the submit button.

Controlled input takes the current value as a parameter and executes a callback function when the value changes.

class NameForm extends React.Component {
  constructor(props) {
    super(props);
    this.state = {value: ' '};

    this.handleChange = this.handleChange.bind(this);
    this.handleSubmit = this.handleSubmit.bind(this);
  }

  handleChange(event) {
    this.setState({value: event.target.value});
  }

  handleSubmit(event) {
    alert('Submitted by name:' + this.state.value);
    event.preventDefault();
  }

  render() {
    return<form onSubmit={this.handleSubmit}> <label> <input type="text" value={this.state.value} onChange={this.handlechange} /> </label> <input type="submit" value=" submit" /> </form> ); }}Copy the code

As soon as the user makes a change to the data, the application immediately knows which state has changed, and we can build a better form interaction and user experience based on the change of state.

The controlled and uncontrolled components can be analogous to the push and pull models of the server and the client. Push is that the server actively sends data to the client and pushes it immediately once there is “data change”, so the user can do processing based on the latest message, while the Pull model cannot know the details of data changes. Even if an error output is encountered, the user can only be notified indirectly.

If your form is simple enough to interact with, only submit validation is required, and there are no complex user interactions such as cascading data, forcing formatting input, etc. Then you can choose uncontrolled components. Of course, selection is not a one-time thing; we can migrate uncontrolled components to controlled components during development.

Full versus incremental problem

In fact, in our life and development, we often encounter the same problem as controlled and uncontrolled components in React. It’s a total versus incremental problem. Based on different fields, different design goals, different users, different teams, current limited resources and current goal setting will affect the final decision of the problem. Here are a few of the problems I’ve encountered recently. For your reference.

Old library TS upgrade

Since last year, new projects have been developed in TypeScript, which is beneficial for large, complex projects. Especially when the business is unstable and facing a lot of change. Dynamic types are always scary. For older projects, we want to benefit from TypeScript as well.

The front-end Vue project has been in development for more than three years, and the current project has evolved from a simple single-page application to a business-based multi-page application. It also splits out a set of base libraries and widgets.

We all know that changes have to be made to upgrade from the base. Currently we have a heavy development schedule, so we don’t have the time and resources to do a full upgrade, and there are Vue business components in the base dependency. The development schedule of Vue 3 at this point also put us in a “dilemma”. So we can only think of changing auxiliary code that is not a component.

We first added TSC compilation configuration, which allows new modules to use TypeScript, and we can modify some of the old code at our leisure.

However, as a dependency library, it’s not enough just to have TypeScript code internally. Furthermore, the boss wants to define files (.d.ts) to assist other projects. So we compile all the TypeScript definition files for the current code using TSC, and then use gulp-INSERT to modify the definition files.

Applets component development

For mobile Sass development, we still have to provide complex forms, and mobile doesn’t require much interaction. Combining setData with applets is very performance-intensive, and unlike Vue, React has a one-way data flow. Therefore, it is better to keep data inside each component. Finally, when submitting, the data of each component is combined for verification and comparison submission, both performance and development experience will be better. So it’s better to use “uncontrolled components” instead for applets form submission.

Of course, the focus of mobile forms is to reduce user input, and the development effort should be invested in the form’s default data to reduce user input operations.

Querying illegal characters

In an era of user-generated value, auditing user-generated data must be a top priority. And our current small program can provide sharing function. The applets themselves have a value-added service called API Security.msgsecCheck to query text security.

At this time, we have two choices. We can check and prompt for illegal characters every time we submit shareable data, so that users can clearly know that there are illegal characters in this data submission. Of course, illegal information can also be suggested in the final sharing, but in the face of such a large amount of data sharing, users may be difficult to find out which information is wrong. Which way is better? It depends on the number of users and the resources invested in the applet.

There are also many examples, such as js file modification, is it incremental (string level) or full (single JS file)? It depends on the company and the project. So what you do depends on your business, the resources you have, and even the level of customers you are dealing with.

To encourage the

If you think this article is good, I hope you can give me some encouragement and help me star under my Github blog. Blog address

The resources

controlled-vs-uncontrolled-inputs-react