preface

Forms have always been an integral part of a front-end project. What if a project needs to develop 200 or so forms in two months? We can also work overtime. Is the quality guaranteed? We need to develop a function that can design forms through visual interaction. I’m going to share with you some of the technical capabilities I used to develop this form designer and the overall design thinking.

Technical capability analysis

  • Front-end capability: basic frame building component drag capability
  • Background ability: basic interface service database design

Foundation design

Interaction design

For interaction design, refer to FormMaking. If you are interested, click on it. The left area is for controls, the middle area is for drag and drop, and the right area is for property Settings.

The control area

  • Basic controls: common controls in the form such as: input box drop-down box switch time selector…
  • Advanced controls: encapsulates some commonly used composite controls
  • Layout control: Grid layout can be divided into multiple lines

Drag and drop zones

  • Base control order adjustment
  • Adjust the order of components within the word sheet

Attribute area

Control properties

  • Basic property configuration: title initial value field value placeholder and other general properties of some controls
  • Data attribute configuration: Data source configuration, static/dynamic static manual input data source value (values in the drop-down table) Dynamic input request URL request method request parameters, request header
  • Check attribute configuration: The form entry’s regular checksum limits some illegal characters
  • Other properties configuration: some display processing submitted processing and so on

The form properties

  • Base property configuration: the name of the entire form and the checksum address of the form
  • Other properties configuration:

Data processing design

General rule design

  • Interface interaction rules
Param2 :""} # headers:[{key:"",value:""}] # headers:[{key:"",value:""}] data:{} || [] }Copy the code
# # PUT interface/API/v1 / test request parameter params: [{filed: "", the value:" "}] # request headers head: [{value: the key: ""," "}] # return value {code: 200, data:{} || [] }Copy the code
  • Data request Rule 1 (ur parameter multiple conditions) 😕 Multiple are separated by ampersand
/path/test? key=_field1&key2=_field2Copy the code
  • Data Request Rule 2 (URL parameter fetch) : Key =self (self indicates the value of the current form item) key=_fieldname (_fieldname indicates the value of another form item or user object) key=external_888(external_value indicates the static value value)
/path/test? search=self&status=_field2&name=external_testCopy the code

Note: Wrap this rule processing into a public method processing request URL named parseRequestParams

Input: / path/test? Search =self&status=_field2&name=external_test Command output: /path/test? Search = own value &status= the value of status in the form &name=testCopy the code
  • Data request Rule 3 (body argument) : Field indicates the form’s field value indicates the value (if not defined, take the form’s defined value, if defined, leave it alone)
[
    {
    field:"",
    value:""
    }
]
Copy the code

Note: The body of this rule is wrapped as a public method and can be named parseRequestBodyData

Input: [{value: the field: "id", "001"}, {field: "demo", value: ""},] output: Value: [{field: "id", "001" (the default value is set)}, {value: field: "demo", "demo values from the form"},]Copy the code
  • Automatic filling rule 1: fill multiple to | | space
fieldname1||fieldname2
Copy the code

Note: Encapsulate the handling of this fill rule as a public method

  • Conditional judgment rule 1: Identifier == equals! Equals means not equal to
key==value key! =valueCopy the code
  • Condition judgment rule 2: when multiple conditions, | | and symbolic representation or && said
key1==2&&key2==3||key3! = 4Copy the code

Note: Encapsulate this rule handling as a public method

  • Text display rule 1: Item.key expressions customize display conditions (to solve complex display logic)
item.lable+'-'+item.value+'/n'
Copy the code

Data acquisition design

/demo/list? id=self&name=_name&_externalCopy the code
  • Drop-down list Data (static) : Static data can be configured
  • Drop-down list data (dynamic) : Interface address parameter fields can be configured
  • Dynamic Query Data (internal) : You can configure the interface address parameter field
  • Dynamic Query Data (third-party) : You can configure the interface address parameter field

Display/read only/must rule processing

  • Rule 1: (multiple conditions) | | symbol or and && said
  • Rule 2 (identifier) : == equals! Equals means not equal to

Verification rule processing

  • Regular check
  • Illegal character
  • Error description

Autofill rule

key1||key2||key3
Copy the code
  • Query auto-fill: fill after query with input values (onblur event processing)
  • Auto-fill after drop-down selection: Fill with the selected value (onblur after query onselect)
  • Static drop-down list after the selection of the drop-down list by selecting the value of the query after automatic filling (onSelect query)

Architecture design

Front-end component design

The front-end component is divided into the following three modules: form design module (design form), form display module (submit form), and form details module (view submitted form).

Form design module

  • Control display component
  • Drag and drop choreography components
  • Property editing component

Form display module

  • Form overall rendering component
  • Single form item rendering component (the most complex part)
  • Rule resolution method encapsulation
  • Dynamic data acquisition encapsulation
  • Unified processing and encapsulation after data acquisition

Form details module

  • Form header information component
  • Basic Information Component
  • Other information components:

Background Schema Design

Form the schema

The form schema design must take into account the universality of the form. According to a normal form requirement, we can divide the form into two parts:

  • Overall form properties: Form name Form submission (address /header) Attached properties of the form (custom)
  • Properties of a single form item: Control type (input box/drop-down box…) , control data source, control label, control field key, other properties (reserved)
  • Multiple form item properties: a combination of single form items
{
  field_name:"",
  label:"",
  type:"",
  property:{}
}
Copy the code

conclusion

As a front-end team grows, some capabilities to improve productivity must be developed over time, and visual scaffolding is one of these capabilities. It might feel complicated when you don’t touch it, and it might feel like nothing more when you get to know it, but when you actually use it in real projects you’ll find it complicated. In my opinion, there are no difficulties in the technical ability of visual construction, no matter the front-end drag and drop, or nodeJS data storage, these will not be our difficulties. The real challenge is to design the interactions we build and the data structures we store with our own pages. So if you’re a front end and you want to do this well you have to really understand the domain of your application, the business requirements of your project.