You might be wondering why DON’t I just use ANTD?

Material UI may not be popular in domestic companies and front-end circles, because they have ANTD. Admittedly, ANTD is indeed a very good enterprise-level solution, and Ali also positioned it in this way. However, as a simple UI framework, it is actually too complicated and encapsulated. Will make users often feel not free, and will make the code repetition and UI repetition too high, but in fact, this is a good thing in the enterprise-level background management system, can make the style and use method unified, reduce the cost of learning. However, antD is often not the best choice for the most important field of the front end, that is, pages with different styles and functions, etc., especially in the product TO C, you can hardly see the shadow of ANTD, while MUI is very good in this aspect, only responsible for the unity of the style of unit materials. The combination, extension and encapsulation is left entirely up to the developer, and this is the beauty of Material Design. Even though Google uses this Design style extensively in their products, you rarely feel a single or repetitive page.

So controlling forms in the Material UI is no different from using forms in any other framework, even the native React application, In addition, many React Hook implementations in the Material UI are in line with the code style officially recommended by React in the future.

In fact, the IMPLEMENTATION of RC-Forms in ANTD is still based on controlled components and state management. Antd actually gives each implementation a new name, and in most cases these names can make your code look messy and difficult to understand. The essential form.create () is actually a higher-order component, and excessive use of higher-order components can unnecessarily increase the DOM level of your code, but the biggest headache is actually getting the most commonly used Form values. If you want to get one or more values individually you need to write a lot of code that you don’t know why you’re doing it, like why the form object of the form appears in the props of the component. If a parent component wants to get the form of a child component, it’s more complicated. You have to bind the ref of the child component to the parent component to validate and evaluate it, and this code is actually redundant, separating the user from the native form completely, making the user overly dependent on ANTD, and even unable to process forms without ANTD.

Controlled components and uncontrolled components

While these two concepts may seem confusing to many people who have been using ANTD’s RC-Forms for years, this is actually the most common way to handle forms in most React applications. Both methods have their advantages and disadvantages. It may be a little more complex to use than antD’s encapsulated components, but the solution is more general and understandable, because in most cases we don’t recommend introducing an entire UI framework for processing forms, and this programming approach is more native and lets people know what they’re doing. The readability of the re-form code is also guaranteed.

The controlled components

Bind a state to each field in the form, input, radio, etc. Each time the input Value changes, setState is reset by onValueChange and the input Value is directly bound to the corresponding Value on state. The advantage of this approach is that state can be easily extracted and formatted by virtue of its nature. Also, every input change is notified, which means every value change can be verified in a timely manner. The problem with this approach is that we need to add a lot of state to the component. If the component has a lot of form items, the state of the component will accumulate a long string, and most of the data is just the last value, so there is no need to set it to state. At the same time, since each change will reset the setState, which means that each input is accompanied by a repeat rendering, and we often do not increase the anti-shake in this case, so the meaning of repeat rendering is not much.

Uncontrolled component

The React control has nothing to do with the React control. Instead, use the ref to directly fetch the form DOM to get the Value. This method is more direct, but it also has many disadvantages, such as the form verification cannot be carried out in time, and the ref has to be manually bound for each node. In most cases, and in most form libraries, implementations are basically based on controlled components and state management.

Match the react – hook – form

This is one of the most elegant libraries I’ve ever seen for handling forms. It has less than 10 apis, and is implemented entirely on React Hook (meaning your React version should also support hooks). The value acquisition of the component does not depend on DOM or state, so there will not be so much re-render. Similarly, its validate is also very useful, because it extends the native validate module in H5, and you will have a deeper understanding of native programming in the process of use. Let’s look at a simple 🌰

const SignInSide = props= > {
  const classes = useStyles()
  const { register, handleSubmit, errors } = useForm()
  const handleLogin = data= > {
    console.log(errors)
    console.log(data)
    props.dispatch(actions.asyncLogin(data))
  }
  const handleAuth = (a)= > {
    props.dispatch(actions.asyncAuth())
  }
  return( <Grid container component="main" className={classes.root}> <CssBaseline /> <Grid item xs={false} sm={4} md={7} className={classes.image} /> <Grid item xs={12} sm={8} md={5} component={Paper} elevation={6} square> <div className={classes.paper}> <Avatar className={classes.avatar}> <LockOutlinedIcon /> </Avatar> <Typography component="h1"  variant="h5"> Sign in </Typography> <form className={classes.form} onSubmit={handleSubmit(handleLogin)}> <TextField inputRef={register({ required: 'no email is dame', maxLength: { value: 10, message: 'too long' }, })} error={Boolean(errors.email)} variant="outlined" margin="normal" fullWidth id="email" label="Email Address" name="email" helperText={ errors.email ? errors.email.message : 'input your email' } autoFocus /> <Button type="submit" fullWidth variant="contained" color="primary" className={classes.submit} > Sign In </Button> <Grid container> <Grid item xs> <Link href="#" variant="body2"> Forgot password? </Link> </Grid> <Grid item> <Link href="#" variant="body2" onClick={handleAuth}> {"Don't have an account? Sign Up"} </Link> </Grid> </Grid> <Box *mt*={5}> <Copyright /> </Box> </form> </div> </Grid> </Grid> ) }Copy the code

Because the Material UI does not provide us with the interface of validate, it just gives us a validation error style in the TextField. Here, we can define different prompts for different validation by combining the error mechanism of RHF. The submitted form data is passed to the handler only after it has passed all the validation, so it can be used freely. If you want to pass it to the parent component, you just need to pass this method through props.

If you feel it is troublesome to use it, you can integrate it with RHF based on the native Input, which is also what the Material UI encourages you to do.

Reference

Controlled and uncontrolled form inputs in React don’t have to be complicated – Gosha Arinich

Understanding and using AntDesign forms – Nuggets

Github-react-hook-form /react-hook-form: 📋 react hooks for form validation without the hassle