Frontend Development 12 min read

Design and Implementation of the Form Designer and Renderer in the 58 Process Open Platform

This article explains how 58's Process Open Platform uses a low‑code approach with a visual form designer and a JSON‑schema‑driven renderer to dramatically improve the efficiency of creating, maintaining, and deploying business forms and approval workflows.

58 Tech
58 Tech
58 Tech
Design and Implementation of the Form Designer and Renderer in the 58 Process Open Platform

The OA system at 58 contained hundreds of business forms and approval processes, each requiring separate development, which resulted in low deployment speed—about one new form every two weeks. To address this, the company built a low‑code/zero‑code platform that lets non‑technical users create and modify forms via drag‑and‑drop, generating JSON Schema that drives both design and rendering.

The platform distinguishes two user groups: form configurators (product operators) who edit form definitions in the designer or generate them via backend APIs, and form users who fill, submit, and view form data and related approval information. Each form is represented as a JSON Schema tree where every component corresponds to an object in the schema.

Form Designer provides a three‑column layout: a component palette on the left, a canvas in the middle where components can be dragged, and a property panel on the right for configuring field attributes such as label, placeholder, validation, encryption, and linkage rules. The designer outputs a complete JSON Schema that can be stored and later rendered.

Form Renderer parses the JSON Schema, maps component types to UI widgets, constructs the form layout, and attaches event callbacks. It supports visibility and content linkage, fetching options from backend services, and dynamic updates based on user input. Advantages include reduced development effort and faster delivery; disadvantages are higher runtime overhead and limited flexibility for highly custom interactions.

The Schema Protocol is a simple, extensible tree‑structured JSON format. Common attributes reside at the root, while node‑specific attributes are stored in fields like visibileProps and contentProps . Example schema snippets illustrate how a leave‑request form is modeled, including components such as SingleSelect , DateTimeRange , and MultiLine , as well as linkage definitions that control visibility and content based on other fields.

Key code examples:

<template>
  <el-row class="render-content">
    <el-col
      v-for="item in formConfig"
      :key="item.name"
      class="render-content-item-box"
      :span="Number(item.attributes.width)">
      <component :is="`${item.type}Form`" ref="formItem" :detail-index="index" :item="item" />
    </el-col>
  </el-row>
</template>
[
  {"name":"applicantName","type":"ApplicantName","label":"申请人","value":""},
  {"name":"applicantDept","type":"ApplicantDept","label":"申请人部门","value":""},
  {"type":"Detail","label":"明细","name":"AsZJ1634892182751","children":[
    {"type":"SingleSelect","label":"请加类型","value":""},
    {"type":"DateTimeRange","label":"日期区间","name":"nPiG1634892209750","value":""}
  ]},
  {"type":"MultiLine","label":"请假原因","name":"NnDD1634892259871","value":""}
]

Stage results show a three‑fold increase in form development speed, a reduction in technical barriers, and extensive adoption: over 100 forms covering 80% of OA system forms, 70,000+ monthly completions, support for eight business systems via API, and a form SDK used in five projects.

frontendJSON Schemaworkflowlow-codeform designerrenderer
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.