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

The purpose of this article is to introduce Form Render (FR), a flying pig open source Form solution. Briefly describe the problem it wants to solve, our concept and settlement method, 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 a dream

  2. What you see is what you Get form designer, drag and drop complete form development. And can be freely customized to meet their own preferences of the unique designer

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

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

This future is actually within reach. FormRender currently has 90% support for 2 and 3

Integrated development experience

The current FR development mode is as follows:

From draft -> to form Designer -> Output Schema -> Paste code directly available. This link is currently the “gold” development model for FR. With detailed documentation, online playground, and Demo examples of new features, the cost to get started is low enough to complete a complex form requirement in as little as an hour (scaffolding up, copy the Demo code, and use the designer to generate the form schema).

The original

You may already have a general sense of form-render, but concerns and questions about “protocol build” are not resolved: this is just a demo.

  1. What is the actual development complexity?
  2. Can complex scenarios be supported? Can linkage be supported?
  3. Can diverse customization be supported?

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

FormRender (hereinafter referred to as FR) originated from the template form generation scheme of Flying Pig Interactive platform in 2017. At that time, the interactive platform had a lot of template development needs, and the resulting 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 configuration form of the platform. For the first solution, developers simply need to comment the component props and the platform form will be generated automatically:

This is a qualitative leap in the development experience. We knew that little form-Render was on the right track. FR has experienced 2 years of landing and polishing in various scenes inside Flypig and group brothers BU, and opened source version V0.1.0 in 2019.09.30, currently iterated to V0.8.2, STAR 1.5K, Fork 157, NPM monthly download 2k

FR currently covers the flying pig internal gameplay platform, interactive platform, building, launching, batch intelligent production, many channels management and other small two platforms, is the official form of flying pig scheme. During the open source period, I supported the establishment, configuration and delivery system of 10+ BU and 20+ scenes for Ali Cloud team, Taobao community team, Taobao new retail team, Ali ARTIFICIAL Intelligence Lab and security intelligence team of the group. Here are some FR usage scenarios:

Building in Ali is a wave of tide, but the personal feeling in the maintenance of FR to really design easy to use and easy to use the building system is not easy, or need to choose. Here is a brief share of my thoughts on design:

Design thinking

Thought 1: Configure vs components

The core of FR is to replace componentized development with JSON configuration. Configuration and components are both abstractions of things. In fact, a component is also a type of configuration (the function of a component is configuration items). Essentially, the difference between them lies in the granularity of encapsulation:

From the perspective of components: Anyone who has written forms by hand knows that even for the simplest form with two boxes, you have to write “glue functions”, i.e. check and submit, etc., which is a time-consuming task, and it is difficult to duplicate and paste repeated requirements to complete reuse.

But switching to the configuration perspective: the interactions between the form and the outside world are focused on submission as a single exit, so glue layer validation, linkage, and support for complex components are all relatively easy to describe in attribute terms. This results in the form scenario being a natural fit for configuration.

Thought 2: Rule-based protocols

With the uploaded form designer, the protocol Schema layer has been weakened, but how to develop a stable and extensible protocol is still almost the most important part of the architecture. The FR protocol follows a few simple rules:

  1. Inheriting the international JSON Schema standard on the body does not start all over again. JSON Schema can describe most basic form information and validation, such as title, Description, enum, default, format, and pattern

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

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

Under all three standards, changes to the protocol layer are incremental from the first FR release, ensuring that users do not have to make significant version migrations.

Thought 3: How to be minimalist

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

A React controlled input looks like this

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

An FR form is as follows, keeping the API as simple as possible

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

The controlled model is more clear to the user: submit = value from state, action form = setState, no longer have to go through the document to find countless submission apis and action apis.

Thought 4: Solutions to complex scenarios

Back to the question:

  1. What is the actual development complexity?
  2. Can complex scenarios be supported? Can linkage be supported?
  3. Can diverse customization be supported?

These are some of the questions that were asked, and of course the answer is yes. The following figure illustrates how FR handles customization requirements (you want to render the form input field with a handwritten component of
) :

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

Interested partners, in the document of 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 functionality support for the underlying protocol & optimization of UI presentation. We nailed the schema extensions, nailed the linkage and custom component solutions, and supported the common requirements that were extracted from the vast number of business connections.

  • Phase II of FR, while extending the Schema further, shifted the focus from THE FR itself to the protocol access side. One of the big pain points for FR (or for most similar solutions) is that schema handwriting is expensive and error prone. We provided the form Designer as a bridge and tried it out along the way.

We also put a lot of effort into documentation: adding detailed configuration instructions, massive demos, and new feature showcase. The new document adopts antD’s document mode and replaces the dry text with a large number of code blocks, while also concatenating the scattered documents of FR and its peripheral products into a system. In the larger FR picture, the second phase focuses on the blue block:

The future planning

There is a gap between the status and future of FR:

  1. So far we’ve only given the basics of one-stop development, but there’s still a lot of work to be done in this closed loop
  2. Users have accumulated many demands in complex scenes, and there are many things to solve
  3. The development of open source projects requires more people to participate, and our open doors and experience for developers are still poor
  4. As usage scenarios become more complex, there are various requirements and challenges to the capabilities of THE FR ontology

So our plan for the coming year will focus on two areas:

  1. The loop of the development experience, which extends upwards to build, includes
    • The form designer has been improved to allow for various forms of customization. Let users really customize a form designer for their own project based on the FR-Generator
    • Unified schema storage and delivery platform
    • A clear entry point for custom component access
    • And exploration in the direction of AI identification
  2. Improvements in the functionality and performance of the FR itself
    • More comprehensive support for linkage and verification, and unified to a functional solution (currently verification does not support functional expression)
    • Complex scenarios ensure user experience, performance improvement and optimization
    • Alignments for advanced usage of JSON Schema, and extensions for more utility features of UI: Schema

The diagram below shows the plan to do in blue in each section

We hope that in a year’s time:

  • Lightweight users can refer to the online demo and complete configuration documents to quickly build up the FR code to complete the form requirements
  • Medium users can use the form designer to drag and drop form protocols and produce code seamlessly
  • Heavy users can find and develop customized components through unified management and schema on the platform to meet customization requirements
  • Migration Users can easily migrate by taking a snapshot of the existing system and generating the corresponding FR code (although there is certainly a manual cost for complex scenarios)

The last

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, the 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.

  • Github:github.com/alibaba/for…
  • Liverpoolfc.tv: X-ray render. Gitee. IO/form – render…
  • Form Designer: X-render.gitee. IO /schema-gene…