Directory:

  • A list,
  • Compare this component to the Form component of Element UI
  • 3. Architecture design
  • Iv. Detailed function description
    • 4.1 WTI-Form global function
    • 4.2 WTI-Form form element functions
    • 4.3 How can I Generate three forms in one JSON configuration
  • High support for automated testing
    • 5.1 Built-in support for automated testing
    • 5.2 Using simple configuration files, you can automatically complete automatic tests
    • 5.3 More awesome automated test support
  • Vi. Future features to be added
    • 6.1 Visualizing form generation
    • 6.2 Connect the product manager with the front end
    • 6.3 Vertical Scaling: Automatically generates back-end code
    • 6.4 Horizontal expansion: Automatic generation of tables and charts
  • Seven,

A list,

The author:

Zero zero water. Have written several 10W +, 1W + blogs. I used to be a front-end developer of Alibaba, and now I am working in a trust state-owned enterprise in Xi ‘an to do technology research and development for Work Life Balance. Good at improving efficiency based on the real situation of the company.

In addition, never inappropriate headlines.

describe

Vue.js low-code form component, secondary development based on Element UI. Named wti – form

The way components encapsulate JS logic is a killer in multi-form page scenarios.

Currently supported form elements include, but are not limited to, the following elements, as shown below:

For more supported features, see the documentation link at the end of section 1

Wti – form features:

Pain points Not ~ often ~ have ~ use ~
There are too many forms to write Writing forms in JSON, CTRL + C, CTRL + V is not a dream
Hate the logic of dealing with complex scenarios? Built-in support for a variety of general and common complex scenarios
Add, edit, view and write the same form three times? A set of code, can pass [add], [edit], [view] three pages, reduce the development of more than 70%
Too much interaction, debugging trouble easy to bug? The internal interactions of the form are cohesive, decoupling the form from the external interactions, reducing the development effort
It’s too cumbersome to write every form element by hand Class ElementUI documentation, which is not only detailed, but also follows each example with code that CV can use directly
I’m only going to use ElementUI Most of the form component’s native properties are supported based on Element UI encapsulation. And much simpler than using ElementUI
Reliable? It has been stably used in the company for half a year and completed hundreds of form pages
Requirements are too strange to be supported by existing components Secondary development is extremely simple, according to the actual needs of the independent addition
I don’t even want to write code Document built-in a configurator, configuration, automatic generation of VUE files, lazy Gospel
The company is poor and develops level dishes Easy to get started, personnel costs are expected to be reduced by more than 50%
Forms are too cumbersome to test Automated testing is naturally supported. And automated testing is supported from both directions!
other Open source! For free! If it is a state-owned enterprise in Xi ‘an, welcome to our company for technical exchange

Try it now! Simple configuration on web page, instantly preview forms to generate results!

advantages

  1. Wti-form can greatly improve development efficiency, with a minimum efficiency increase of 200% and a maximum efficiency increase of more than 1000% (both compared to using Element UI);
  2. The documentation is extensive and detailed, with lots of sample code. And the documentation itself is open source;
  3. Support through web page configuration, quick generation of front-end code (a whole Vue file) function (see documentation);
  4. A component that supports automated testing is being developed. After integration, form elements can be automatically inferred and filled in based on form configuration (Python support library will be developed in the future for easy integration into automated testing code);

Applicable people

  • Technical teams with a lot of form pages but a tight staff/budget;
  • Back-end developers who are not good at the front end, but need to write front end form pages (e.g. do personal work);
  • Developers who already use Element’S UI but want to reduce duplication;
  • The technical leader who wants to improve the code yield and reduce the number of bugs in the early and middle level development of the uneven level of front-line developers;
  • General development teams (customizable value UI styles based on components);

Github and documentation address:

  • Component source code: github.com/qq20004604/…
  • Documentation source: github.com/qq20004604/…
  • Document address: lovelovewall.com/wti_form_de…

Compare this component to the Form component of Element UI

Because it is secondary development based on Element UI, it must be more convenient and powerful than using Element UI to develop, otherwise there is no value in development.

So compare this component to the Element UI to help you understand the benefits of this component.

Attached is Figure 1, which has been highlighted for the core points

The functionality currently supported by the form component is shown in Figure 2

3. Architecture design

Source code address: github.com/qq20004604/…

Previous architecture layering diagram, with Figure 3:

Again in Figure 4, component event flow.

Combined with Figure 3 and Figure 4, in general, the ARCHITECTURE of WTI-Form can be understood as follows:

  • Data layer: the core is [form data] and [configuration data], while other data are dynamically calculated based on these two and will not be stored separately.
  • UI layer: The UI is dynamically generated from configuration data, so if the incoming configuration changes, the UI changes dynamically.
  • Event layer: Based on the generated UI, user actions trigger the event layer. The event layer ultimately affects the form data.

Therefore, for the entire component, the developer only needs to care about two pieces of data, and the UI and events derived from that data. Therefore, the data does not exist from the same source but is stored in multiple places leading to possible conflicts and consistency, so it is easy to write highly reliable code.

And based on this design, secondary development is also a very simple thing.

But due to space constraints (no, because I’m lazy), this is missing:

  • The event flow of the child form, and the interaction between the parent form and the child form;
  • The design of associations between forms and form elements;
  • Methods for secondary development of their own internal components based on personal needs;

Iv. Detailed function description

4.1 Global functions of WTI-Form:

  • Generate forms from JSON data;
  • Assign values to each element of the form using data;
  • Support form verification;
  • Forms support block display;
  • Support single block fold up, expand, all fold up, all unfold;
  • Support switching form display mode: long form/short form with TAB switch;
  • Support for disabling form elements globally (for example, when submitting);
  • Support to add a box to the form, increase the distinction;
  • Support to switch form mode to plain text display mode;
  • Support to set the form to a row of four columns/two columns/one column;
  • Redeveloping custom form elements is extremely difficult;
  • I don’t want to write anything else;

4.2 Functions of WTI-Form elements:

  • Support setting default disable, default hide, default value;
  • Supported Settings This parameter is mandatory.
  • Different forms support different validation rules, and you can also customize validation rules (like Element UI).
  • When the value of a form element is the specified value, the linkage can set the value of another form element/set hidden/set disabled/set mandatory.
  • Support for custom styles;
  • Custom placeholder support;
  • Support text input box, number input box, amount input box, date input box, date range input box, dynamic drop-down box (automatic request data dictionary), ordinary drop-down box, time input box, single box, percentage input box, text field input box, etc.;
  • I don’t want to write anything else;

4.3 One JSON configuration generates three forms

Paste figure 4 again:

That is, developers typically only need to provide JSON describing the form structure and call validation methods to complete a form.

If you need to initialize data (say, a form editing page), the initialization data is identical to the submitted data structure.

If you want to view content (such as a detail view page), use the same method as in edit mode by setting the text-model value passed to the component to true (to enable plain text mode). In plain text mode, even the dictionary drop-down interface, which returns the value dictionary, is automatically translated as a label.

One might wonder, would form structure JSON be too complicated?

Of course not, please refer to the documentation page: lovelovewall.com/wti_form_de… When you open this page, think about how many lines of code you would have to write to implement this feature (various linkage, three different forms, and interaction).

Then look at the source of this page github.com/qq20004604/…

There is no doubt that this list, at least, reduced development effort by 80-90%, so the 1000% increase in efficiency in the title is not an exaggeration, but simply a statement of fact.

High support for automated testing

5.1 Built-in support for automated testing

When testing a form page, there are several common challenges:

  1. If the form is too large and has too many elements: If you test manually, you have to fill in many form items at a time, which can be a waste of time. If it’s an automated test, grabbing form elements one by one and filling them in can be a waste of time.
  2. Too many forms: automated test logic has to be written for every page, which is a waste of time.
  3. Form element changes: When form elements change, it can be a waste of time to change the automated logic code;

Therefore, when faced with a large number of form page scenarios, the minimum test complexity is O(n²), and it is easy to miss the test.

In this case, WTI-Form is friendly to support automated testing.

5.1.1 Form element positioning

For the first problem, if there are too many form elements, we need a way to quickly locate each element.

A solution is provided for this situation: use a unique class to locate.

In particular, suppose the following is the HTML of an input field

<div data-v-14c4e670="" data-v-74ae480c="" class="form-input-box form-item-box form-unqiue-name"> <div Data-v-14c4e670 ="" class="el-input el-input--suffix"> <input type="text" autocomplete="off" placeholder=" please input user name" class="el-input__inner"> </div> </div>Copy the code

In my design, every element that has a key must have a class that is form-unqiue-${key}. Therefore, you can use this unique class to find the element in the page.

Therefore, you can encapsulate a class and retrieve the value \ by calling class to find the corresponding form element through this unique class. Example code is as follows:

Def findEle(self, key, type): ele = None if type == "input": ele = self.findInputEle(key) ## some other element type else: Ele = self.findxxele (key) return ele # 1, def findInputEle(self, key): Def findXXEle(self, key): def setVal(self, ele, type, val) Def getVal(self, ele, type): passCopy the code

You can get the form element, get the value of the form element, and set the value of the form element simply by passing in the element’s key and type (or even without type).

No matter how the requirements change, just change the input parameter. As a result, there are too many form elements, and you need to obtain the expression elements one by one, increasing the test workload problem is solved.

5.2 Using simple configuration files, you can automatically complete automatic tests

Based on the 5.1 approach, we can solve the problem of form fetching elements.

Next we have to face is how to carry out various tests, such as whether the required is not filled in can be submitted, whether the length of the limit is too long or too short can pass verification, etc.

So, based on the front-end JSON configuration, by writing a utility class, we can automatically infer what the data for each form element is for its various test scenarios from the rules.

If you can do this, the problem of too many forms and writing test scripts will be solved.

There is basically no technical difficulty to complete the whole process. If you do not know how to achieve it, you can add me to wechat to communicate.

5.3 More awesome automated test support

Currently writing an automated test component that looks like this:

  • Pass the form component into this component;
  • The component will automatically infer what data should be generated for each key based on the JSON configuration and the component’s own configuration.
  • Currently, three kinds of data are supported: [standard legal data] [legal boundary data] [illegal over-limit data];
  • For special support user – defined data generation;

However, due to my laziness, the current development progress is only about 10% (mainly because leaders do not pay attention to this thing), and only support the data generation of [text input box].

Please refer to this section of the documentation: lovelovewall.com/wti_form_de…

Vi. Future features to be added

The functional architecture design of the form itself has been relatively perfect, and it is not difficult to add more form element types in secondary development.

Therefore, starting from the form, through the whole development process, can more effectively improve the efficiency of development.

6.1 Visualizing form generation

Different from the C-side scenario, the B-side scenario is more common for processing flows. There are many forms in a process, and many of these forms have the same form elements. This means that these form elements can be reused in large quantities.

Therefore, we can develop a back-end service dedicated to storing these developed form elements.

When developing a new page, you can search for previously written form elements by keyword, then drag them directly into the form through a check/drag pattern, and eventually generate a Vue component or even a page directly. This is now the most common use of low-code platforms.

We currently have a general version of this solution (stronger than the one provided in the documentation), but it’s still not perfect enough to be applied to all forms.

This is why this form component can be called a low-code form component.

However, because this is part of the company’s business code, you can’t give code and examples directly.

However, in the document, to a [through the web page directly generate form] function, belongs to the basic version, enough for general development use.

Lovelovewall.com/wti_form_de…

6.2 Connect the product manager with the front end

In 5.1, we are still purely at the front-end code level. But for modern development, we can certainly imagine more.

The product manager decides what the form looks like. When they communicate it to us, they have an Excel that describes the rules for each element in the form.

So, can we make a tool to directly get through the product manager and front-end development? I think it is totally possible.

Imagine, for a moment, the rules that allow you to configure form elements, based on the tools provided in the quick Form Creation document. Then an Excel is generated based on this, so this is the product manager’s element sheet.

At the same time, we store this data to the back end, from which the front end can generate Vue files directly using code generation tools (FastCreate functionality in the documentation).

As a result, we did not increase the work of the product manager, and because of the tools we provided, the product manager reduced his workload and made it easier to maintain.

But at the same time, the front-end workload is greatly reduced, the front-end only needs to re-develop some special functions based on the already written Vue file.

This means that the team’s demand for front-end development may be reduced by more than 50%. All that brings is lower research and development costs.

6.3 Vertical Scaling: Automatically generates back-end code

When we get through the product manager and front end, we can definitely get through the product manager and back end development line as well.

Based on the current design, when we decouple the form from the element, we can predict exactly what the data will look like on the page.

In other words, which elements are required, non-required, length, and type are predictable.

As it happens, the backend also needs these things to validate form submissions during form validation. Therefore, we can directly generate back-end code based on this, which can reduce a lot of back-end development effort.

Because it is generated automatically, when the product manager updates his requirements (form elements), the back end can be generated again through the tool without manual maintenance.

More importantly, the backend code generated in this way does not have inconsistent field verification rules due to communication problems.

No doubt, this can also improve engineering reliability.

In addition, it can also do type/data inference based on the existing Excel and front-end/back-end code. When the product manager adds a new element, it can intelligently guess the type and rules of the field according to the existing data.

6.4 Horizontal expansion: Automatic generation of tables and charts

In general, once a form is submitted, it is sometimes necessary to preview it through tables and charts.

Therefore, in the case of such scenarios, we can also write a tool to automatically generate charts and table codes based on stable and reliable data sources.

You can even reuse the JSON configuration and write a conversion function that automatically generates tables/charts.

It’s not that difficult.

Seven,

All in all, WTI-Form, in terms of ease of use, professionalism, and efficiency of development, beats most forms components on the market and requires no additional learning costs.

And if you’re already using ElementUI, there’s no cost or risk to developing new forms using this component.

Whether it is private back-end developers, limited cost and manpower, technical leaders working overtime every day, toB scenarios need to write a large number of form pages of small and medium-sized software development enterprises, are the best choice.