Making: github.com/alibaba/for… To support the development of open source projects, welcome to Github Star!

This article introduces Form Render (FR), an open source Form solution from Alibaba. Briefly describe the problems it seeks to solve, our philosophy and approach to reconciliation, the road we have traveled in the past six months, and FR’s future plans

In the future

What will the form development experience look like in the near future?

  1. Upload a screenshot of the form, identify and generate usable code, and make the migration of the old system like a dream

  2. Wysiwyg form designer, drag and drop to complete form development. And can be customized to meet their own preferences of the unique designer

  3. A development platform that aggregates all of the above tools, on which you can uniformly maintain and store forms, generate corresponding storage addresses, and place them in business with only one URL

    // Request unified platform to get the corresponding display
<FR url={"https://..."} / >Copy the code

That future is actually close at hand. FormRender currently has 90% support for 2 and 3

Integrated development experience

The current FR development pattern is shown below:


From draft -> to Form Designer -> Output Schema -> Paste code is available directly. Currently this link is FR’s “gold” development model. With extensive documentation, online playground, and examples of new feature demos, the cost of getting started was low enough to complete a complex form requirement in as little as an hour (set up scaffolding, copy the Demo code, and use the designer to generate the form schema).

The original

Now that you’ve got the general feeling of form-render, you still have some concerns about protocol construction: this is just a demo.

  1. How complex is the actual development?
  2. Can complex scenarios be supported? Can linkage be supported?
  3. Can you support diverse customization requirements?

The answer is yes. Before answering these questions, let’s briefly introduce FR’s original intention and design thinking:

FormRender (hereinafter referred to as FR) originated in 2017 as a template form generation solution on Feizu Interactive platform. At that time, the interactive platform had a large number of template development requirements, and the output template needed to be open to the operation for online configuration and delivery. For developers, they not only had to develop components, but also produce the platform configuration form. We gave the first scenario, where the developer just needed to comment on the component props and the platform-side form was generated:

This is a qualitative leap in the development experience. We know this little Form-render is on the right track. After 2 years of implementation and polishing in various scenarios within Fepig and group sibling BU, FR opened source on V0.1.0 in 2019.09.30 and is currently iterating to V0.8.2, STAR 1.5K, Fork 157, 2K NPM monthly downloads

FR is currently the official form scheme of Flying Pig, covering primary and secondary platforms such as internal gameplay platform, interactive platform, construction, delivery, batch intelligent production and numerous channel management. During the open source period, I supported ali Cloud team, Taobao community team, Taobao new retail team, Ali artificial intelligence laboratory and security intelligence subordinate to build, configure background and release system of 10+ BU and 20+ scenes. Here are some FR usage scenarios:

Building in Ali is a big tide, but when MAINTAINING FR, I feel that it is not easy to really design a good and easy to use building system, or it needs to make a choice. Here is a brief share of my thoughts on design:

Design thinking

Thought 1: Configuring VS components

The core of FR is JSON configuration instead of componentized development. Configurations and components are both abstractions of things, and in fact components are a type of configuration (the props of a component are configuration items). Essentially they differ in the granularity of encapsulation:

From the component point of view: Those of you who have written forms by hand know that you cannot avoid writing “glue functions” for even the simplest form with two boxes, such as verification and submission. It is a time-consuming task, and it is quite difficult to reuse the form by copying and pasting.

But switch to configuration: the form’s interaction with the outside world is focused on submission, so glue layer validation, linkage, and support for complex components are relatively easy to describe in attributes. This makes the form scenario a natural fit for configuration.

Thought 2: Regularized protocols

The protocol Schema layer has been weakened with the introduction of an uploaded form designer, but creating a stable and extensible protocol is still almost the most important part of architecture. The FR protocol follows a few simple conventions:

  1. JSON Schema can describe most of the basic information and verification of forms, such as title, description, enum, default, format and pattern

  2. Common presentation description for all elements, described using “UI: XXXX”. For example, “UI: disabled” : true

  3. Only the presentation descriptions required for certain form elements are placed in “UI: Options”

Under all three standards, FR changes to the protocol layer are incremental from the first release, ensuring that there is no major version migration for users.

Thought 3: How to be minimalist

The slogan of FR is: Write a form like an input

A React controllable input looks like this

<input value={this.state.value} onChange={this.onChange} />
Copy the code

An FR form is shown below, keeping the API simple to use

<FormRender
  schema={schema} // Describe the form UI
  formData={this.state.value}
  onChange={this.onChange}
/>
Copy the code

The controllable model is clearer to the user: submit = value from state, action form = setState, no longer need to find countless submit and action apis in the documentation.

Thought 4: Solutions to complex scenarios

Back to the question:

  1. How complex is the actual development?
  2. Can complex scenarios be supported? Can linkage be supported?
  3. Can you support diverse customization requirements?

These are the questions I just posed, and of course the answer is yes. The following image nicely illustrates how FR handles the need for customization (you want to render the form’s input field with a
hand-written component) :

As for linkage, here is a schema that was released a few days ago when some friends in the group asked questions. I’ve never written this long before

Interested partners, in the document how to linkage and custom component modules are given a detailed description and Demo.

What did FR Ii do

  • The focus of THE FIRST phase of FR was on functional support for basic protocols & optimization of UI presentation. We finalized the schema extension, finalized the linkage and custom component solution, and supported the common requirements extracted from the massive business docking.

  • In the second phase of FR, the emphasis was shifted from FR itself to the protocol access side while further expanding schema. One of FR’s sore points (or one common to most of these solutions) is that Schema handwriting is expensive and error-prone. We provided the form designer as a bridge and used it as a base to try out a few more on the way. In the FR picture, the second phase focuses on the blue block:

The future planning

There is a gap between FR’s present and future:

  1. So far we have only given the basic capabilities of one-stop development, but there are still a lot of imperfections in this closed loop
  2. Users have accumulated many appeals in complex scenes, and there are still many things to solve
  3. The development of open source projects requires more people to participate, and our openness and experience for developers is still poor
  4. As usage scenarios become more complex, there are various requirements and challenges to the capabilities of FR ontologies

So the focus of our planning in the next year is two parties:

  1. Build up and extend, improve the closed loop of the development experience, including here
    • The perfection of the form designer allows for various forms of customization. Allow users to actually customize a form designer for their own projects based on fr-Generator
    • Unified schema storage and distribution platform
    • Customize the explicit entry point for component access
    • And the exploration of AI recognition
  2. Improved functionality and performance of the FR itself
    • More comprehensive support for linkage and verification, and unified to the functional solution (currently verification does not support functional expression)
    • Complex scenarios ensure user experience, performance improvement and optimization
    • JSON Schema advanced usage alignment, UI: Schema more utility extensions

Map out what to do in each block in blue

We hope that in a year:

  • Lightweight users can refer to online demos and complete configuration documentation to quickly assemble FR code and complete form requirements
  • Intermediate users can generate form protocols through form designer drag-and-drop and produce code seamlessly
  • Heavy users can use the platform to manage and put schemas in a unified way, and find and develop customized components in a unified way to meet their customization requirements
  • Migration users can easily migrate from a snapshot of the existing system to generate the corresponding FR code (of course there is a certain manual cost for complex scenarios)

The last

I love Steve Jobs’s quote: “Life can be so much broader, once you discover one simple fact: that everything around you that you call ‘life’ is made up by people no smarter than you. And you can change it, You can influence it, you can build your own things that other people can use.”

Translated into Chinese, FR is essentially a React component with extremely low code barriers. When you have a problem with FR, realize that you can come in and contribute two lines of code. Welcome to comment, issue and join the group.

Making:Github.com/alibaba/for…Website:X-ray render. Gitee. IO/form – render…Form Designer:X-ray render. Gitee. IO/schema – gene…Nailing group: