There are two common approaches to developing forms: one by configuring code and the other by composing components. Forms generated by configuration code are called Dynamic forms, while forms generated by composition of components are called normal forms.

I’ve found a lot of people who love dynamic forms, and in the dozen or so projects I’ve worked on, whenever there’s a form requirement, someone will try to configure code to generate one. But are dynamic forms really appropriate for all business scenarios? What are the pitfalls of dynamic forms? How should we apply dynamic forms to our projects? I will examine each of these questions in the article.

This is a two-part series: In the first article we’ll look at scenarios where dynamic forms work, and in the second we’ll look at how to design and implement complex dynamic forms:

Dynamic forms (Part 1) – Stop abusing dynamic forms

Dynamic Forms (Part 2) – How to implement complex dynamic forms

Configuration VS Composition

I mentioned two common ways to build forms: configuration and composition. Let’s take a concrete example of how to implement forms in these two different ways.

Suppose we complete a form to collect personal information, including gender, age, and income. As follows:If we use the combinatorial approach, we would write something like this:

export const ProductForm = () = > {
  return (
    <form onSubmit={onSubmit}>
      <div className={"form-body"} >
        <Select
          name={"gender"}
          label={"Gender"}
          options={genderList}
          value={formValues.gender}
          onChange={onFieldValueChange("gender")} / >
        <Input
          name={"age"}
          label={"Age"}
          type={"number"}
          value={formValues.age}
          onChange={onFieldValueChange("age")} / >
        <Input
          name={"income"}
          label={"Income"}
          type={"number"}
          value={formValues.amount}
          onChange={onFieldValueChange("income")} / >
      </div>
      <div className={"form-footer"} >
        <button type={"submit"} >Submit</button>
      </div>
    </form>
  );
};
Copy the code

Using the configuration approach, we would write something like this:

const formConfig = {
  title: "Personal Information".description: "Please fill in personal information".fields: [{type: Select,
      name: "gender".label: "Gender".value: "F"}, {type: Input,
      name: "age".label: "Age".value: ""}, {type: Input,
      name: "income".label: "Income".value: "",}].}export const ProductForm = () = > {
  return (
    <form onSubmit={onSubmit}>
	      <div className={"form-body"} >{ (formConfig.fields || []).map(({type, name, ... others}) => { const Field = type; return (<div key={name}>
                <Field
                  name={name}
                  onChange={onFieldValueChange(name)}
                  {. others} / >
              </div>)})}</div>
      <div className={"form-footer"} >
        <button type={"submit"} >Submit</button>
      </div>
    </form>
  );
};
Copy the code

With this comparison, it’s easy to understand why many people are so passionate about dynamic forms. For dynamic forms, we only need to define a uniform configuration template, and then when new forms or input items, we only need to modify the configuration file, which is very simple and convenient. There is also a lot less repetitive HTML template code than in the combined approach.

The configuration code that generates dynamic forms is typically stored in the back end and made available to the front end through an API. But the dynamic form in this article also includes a way to store configuration code on the front end.

So, are dynamic forms really better than regular forms? Please read on.

Application scenarios for dynamic forms

The word dynamic form is very confusing, because the word “dynamic”, at first glance, will make many people feel that it is very flexible, can adapt to many business scenarios. But the biggest lack of flexibility in dynamic forms is that they are only suitable for forms with relatively fixed business requirements and UI.

For example, the requirements of your project are almost all questionnaire forms for collecting user information, and the UI of these forms is very uniform:

  • Each entry takes up a whole column, from top to bottom
  • Label and input fields are arranged up and down
  • Form consists of three parts: form name, form content, and submit button

In this case, there is no problem with using dynamic forms. But if the requirements are so variable and every form has a different style and layout, then I urge you to give up using dynamic forms as soon as possible. Take this example:

From a requirement standpoint, these forms are not in the same class of forms, and the layout of each form is different. Therefore, it is difficult to generate these forms from the same set of templates. Some people might say, wouldn’t it be enough to configure the width of each input as well? Yes, you can do that, but it doesn’t solve the problem. Because business scenarios are inherently different, the UI, layout, and interactions of these forms are largely inconsistent. Even if you meet your business requirements now by adding configuration items, what if requirements change later? Constantly adding configuration items? Therefore, it is not recommended to consider a large number of style requirements in the configuration. If you use configuration to set different styles for different forms, don’t you force the configuration into a special set of code? Instead, write code!

summary

Having said that, let’s summarize the scenarios where dynamic forms are applicable and the issues to consider when choosing dynamic forms:

  1. Dynamic forms are suitable for scenarios with a large number of similar form requirements: the type of input controls is fixed, and the UI and layout are relatively uniform. This makes it easy to define schemas and generate forms directly through a simple loop
  2. Choosing dynamic forms should not only be a technical decision, but also consider business requirements and UI design. Don’t choose a dynamic form solution just because a few lines of HTML code repeat themselves; realize that some repetition is “necessary” and that choosing the wrong dynamic form solution will reduce your development efficiency
  3. Once you’ve settled on a dynamic form solution, you should make some compromises in terms of flexibility and not accept the ever-changing UI design. This point to develop, business, design multiple role communication cooperation
  4. Do not configure specific CSS styles through configuration files. You can encapsulate some fixed styles, such as a two-column/three-column layout, and then switch them through configuration items.