Json-schema Remote form rendering – Solution research

background

After the scene statistics of the team’s middle and background projects, we found that the query list and new edit page occupied an absolute proportion of the number, so the form scene naturally became the focus of development and efficiency improvement.

With the development of middle and back office business:

• Project maintainability deteriorates. The main reason is that there will be some “boulder lists” in the project that are difficult to maintain. Although the number is small, once the evaluation is careless, it is easy to cause development delay. On the one hand, the business logic it bears is complex enough; on the other hand, it is also due to the lack of unified development norms and frequent changes of developers, resulting in technical debt. Moreover, it is obviously unrealistic to solve this problem from the two aspects of normative strong constraints and maintenance of personnel stability if we rely entirely on causality.

• There is duplication of work. Many of the pages in the middle and back are similar in length, such as the regular query list pages. Developers often don’t get any technical enthusiasm or accomplishment from the copy-and-paste process, so hopefully valuable energy will be spent on more progressive and challenging things.

• Requirements implementation increasingly relies on remote dynamic rendering capabilities. The most common is the need to log in according to the identity of the role, different fields. In addition, in some requirements, although the background only involves a very small amount of field changes, it also needs to open a long “accompany running online” with other terminals.

In order to solve these problems, it is necessary to introduce clearer form description and remote dynamic rendering and other core capabilities. Therefore, we want to try to solve the pain points in our project by using the powerful expression ability of JSON-Schema in another way of development.

Domain language:

As a very classic field in front-end development, the form scenario has formed a set of exclusive domain language. At the same time, for the efficiency of subsequent reading and communication, it is also necessary to unify the noun explanation of form technology.

• Json-schema: in a narrow sense, it refers to a form field description protocol that meets the standard JSON-Schema specification. However, this specification is a pure field expression. In real business scenarios, additional expressions such as UI layout, verification and linkage are often required. Therefore, JSON-Schema in a broad sense can also refer to the final rendering protocol after personalized extension based on the general specification.

• Dynamic syntactic expressions: Form functions such as linkage and validation all involve logical computation. In JS, the compilation of logic depends on variables, termview operations, functions, etc., but JSON is naturally deficient in these. In order to make up for this, most forms supporting JSON-Schema support the use of specific template syntax strings to enhance some logical expression capabilities of JSON-Schema. Similar to visible:”{{formdata.x. y === ‘1’? True: false}}”.

• Form-render: Renders a form to a user interface based on a field description protocol, such as Formily, X-render, react-schema-form, etc.

• Form-editor: also known as form designer, visual form configurator. It is the core component of the background visual generation of JSON-schema. It is responsible for the friendly drag-and-drop interaction, and finally generates and exports a rendering protocol to drive the foreground form rendering.

• Remote dynamic rendering: simply speaking, it is a set of technical solutions combined with the above background form editor + foreground renderer. The general process is that the background drags and generates jSON-schema, and the foreground parses and renders it through the supporting renderer.

• Linkage:

  • Active linkage: To actively control the status of other fields by monitoring the changes of specific fields (common state changes include explicit and implicit, value changes, and verification rule changes).

    “XXX has changed in me, and XXX needs to be triggered to make XXX change”

  • Passive linkage: Whether the state of a field needs to change depends on whether the dependent field has changed.

    “Whether I need XXX is because the XXX I rely on has changed.”

• Check:

  • The back-end service interface can be synchronized or asynchronous based on whether it needs to be adjusted.

Common mistakes:

1. Surely the introduction of JSON-Schema can improve the maintainability of the code?

   First, using handwritten JSON to drive form rendering makes the code less maintainable than JSX, rather than better. The main performance is:

   • The reusability of the code becomes low. Because a JSON configuration is not as flexible as JSX, it can be split up and reused into pieces.
   • UI layout handling is also less flexible than writing JSX directly. Json-shema’s strength is in describing data models, not views.
   • The TS type prompt is missing. TSX developing a form can get TS type prompts everywhere, and some pre-written business enumerations can also be automatically prompted in vscode, which is very convenient, but JSON is obviously difficult to do.

   Summary: JSON is naturally better suited for machine parsing than manual maintenance by front-end developers on the page. This is why formily offers a variety of development modes, such as its MarkupSchema Schema, which is better for front-end handwriting, and json-schema, which is better for remote rendering. So, above all, you need a form editor to visually generate the JSON, rather than writing it manually.

2. Json-schema can greatly simplify form development.

   The answer is no. First of all, the complexity of form development depends fundamentally on the complexity of the business logic. It uses a visual background to generate JSON to drive foreground form rendering, but the way of function implementation has changed, from the developer writing JSX code, to the development or operation to visually manipulate the various options of form fields. Often in terms of workload, it is not reduced, but often because JSON expression is not as good as Turing-complete JS, it is not flexible enough. The difference is somewhat similar to the difference between writing Markdown and editing Word.

   The core strength of JSON-Schema is dynamism and visualization.

   1. Dynamics. Avoid frequent online, simple field changes, such as removing a form item, adding a list display item, etc. Can achieve one-click publishing, do not need a long compilation online process. In some business scenarios, different operation fields need to be issued according to the identity of the current logon, and the linkage and verification rules may be different, which is a strong requirement.
   2. Visualization. With the powerful expression ability of JSON-schema, the background form configuration can be realized. Greatly reduce the development threshold, do not need to learn react, ANTD and other technology stack can also be through simple operation training, by dragging and dropping can generate a form page.

Market open source scheme comparison

According to our requirement scenario, we determined the core appeal of the form renderer:

• Remote dynamic rendering capability. Json-schema support, that’s a hard requirement, So formIK, react-final-form, react-hook-form, and a bunch of other forms libraries that focus on one aspect of the form world — extreme performance, better hook support, more advanced data management, etc. — are out of the question.
• Support perfect dynamic logic expression ability. At the JSON-schema level, it can fully cope with some linkage and dynamic verification scenarios. And it’s best to have some bottom-line thinking, such as the js function that provides dynamic syntax and can write strings by hand if it doesn’t meet the requirements (preferably to solve the problem of scope).
• Have perfect ability to customize. If the built-in components cannot meet the requirements, you can quickly access them in the way of customized components. There are custom calibration rules, copywriting and so on.
• Have the ability to express UI layout.
• Ability to work with asynchronous data sources is a plus. Such as a drop-down option, the option needs to be pulled asynchronously from the back end, which is a very common requirement. The difficulty, however, is getting a static JSON to represent an asynchronous request.

The main open source renderers supporting JSON-Schema in the market include:

• Formily2, co-built by Ali Group, is the most influential open source form library in China. Positioning focuses on addressing pain points in complex form scenarios.
• X-render Ali Flying pig, positioning is very easy to use in the background “form/table/chart” solution.
• Formast is designed by Tencent Mozi Studio to be a universal dynamic form solution.
• React – JsonSchema-form A react component for building Web forms from jSON-schema.

React-jsonschema-form can be ignored because it is heavily coupled to the UI framework of Bootstrap.

Formast doesn’t have a very good open source vibe and update frequency, so far it’s a bit internal, but its powerful dynamic syntactic expressions are impressive, and it’s the only form library that supports asynchronous data sources at the JSON level.

Formily has reconstructed many versions along the way. The current v1-V2 upgrade still has a big fault update, and the cost of getting started is still very high. I struggled with it for a long time, but finally GAVE up. However, I agree with its concept very much. It focuses on solving complex form scenes, so it creatively proposes concepts such as Effects, path system and Reaction to solve boundary problems in various form fields. Remote rendering based on JSON-Schema is only one of its non-core capabilities. MarkupSchema is where it gets the most value. So, taken together, it doesn’t quite match our needs.

Taken together, X-Render is one of the most balanced. Although it has no advantages in asynchronous data sources, dynamic logical expression, etc., its custom component features are very convenient to use, and the cost of custom extensions is the lowest once the built-in features do not meet the requirements.

conclusion

X-render itself comes with an open source form editor. Basic interactions such as material drag and drop are already integrated, so the entire form editor can be developed on top of it. In the renderer part, we can use its easy-to-use ability to customize components to encapsulate the built-in components with a layer of asynchronous logic to support the missing asynchronous data sources and other functions, which will have strong scalability. There are some mature online examples in this x-Render practical application set, which is a great source of confidence in choosing X-Render as the final solution.