preface

For a simple list page, we see only one title, one form (form), and one table (table), and to implement this we need to do at least a few things

  1. Draw the interface, including the list and the corresponding pop-up button list
  2. Bind table and form data according to the back-end interface and test the interaction
  3. Bind the pop-up field of the list by back-end port

At this point, the normal front end would be a phased end, and the list page would basically complete a basic user interaction, but the test case running with DACHang would have some errors:

  1. Error tolerance of search conditions, input conditions blank at the beginning and the end, the retrieval of the corresponding project, tens of thousands of words can be input data, and directly lead to server crash after retrieval
  2. A search condition takes effect when the search is not clicked
  3. After the page modification operation, the page does not obtain data again or the page is directly refreshed to the first page
  4. If there is only one data item left on the last page, if no data is displayed after deletion, the page number is the last page
  5. When you return to the page after leaving the page to view details, all search criteria are lost

After fixing all of the above process details, we can’t help but find a simple page that will certainly take a front end close to a day’s work or more. And what’s even scarier is that the front end, in general, doesn’t generalize the interaction design, doesn’t aggregate the interaction design with him and his team, and then the same problem, this person, this team, will do it again in the near future.

problem

We can see from the above work that the current front-end work is mainly composed of interface coding, front-end interaction design and implementation, and back-end data binding. Each of these three sides faces such problems

Interface codification faces:

  1. There are no real designs available, and they don’t take into account the size of the actual interface and how the computer screen responds to changes
  2. Duplicate layouts, different front ends do, even if one system produces two copies of code that are different and of unequal quality

Interaction design and implementation face:

  1. Design results, the team and individuals have not accumulated, the same mistakes, repeatedly promoted
  2. Product interaction design, designed by different front-end tends to lead to different experiences,
  3. If the above two points are satisfied, the huge workload is tiring and easy to lead to the loss of unknown details
  4. Different people do the same design, waste of work, one person design others copy, and because of the code level and other reasons difficult to achieve

Back-end data binding:

  1. The back-end team interface document is implemented first and then output, resulting in the development of the front and back ends cannot be separated, and the whole development mode falls into the trap of development first
  2. Product, back end, front end the same work is highly repetitive and laborious, and the further downstream you are in development, the more difficult it becomes.

In addition to the above problems, small and medium sized companies are also facing the danger of hindsight, which is that the company unit is more than three times less efficient than large companies, which are developing with visual and microcode platforms while we are still coding for business and fixing business.

Establishment of front-end UI framework and business encapsulation system

Front-end problems arise over a short period of time, and the problem can be solved gradually by means of incremental enhancement. To solve the above problems, the first step should be to solve the repeated functional business encapsulation. Why does the functional business repeat? First, it is difficult to package, and second, there is no suitable carrier. If we were to encapsulate a list page as a component, it would be almost impossible to accommodate a variety of search criteria and single-line data processing. Since we will not be able to encapsulate the whole because of the differences in some parts of the whole, can we first encapsulate the parts and separate the functions of the parts into components, so as to easily complete the overall object-oriented parent class encapsulation by reducing the difficulty of the parts. Based on this idea, we can build a UI component library with partial function encapsulation as the goal, and a sample project with accumulated business parent class object as the goal, different front-end through inheriting the parent class to achieve page writing, to achieve the purpose of solving the repetition

How to build an efficient, edible, object-oriented UI component? My idea is to build a JSONized component library, by exposing fields, hook functions and ordinary functions, let the component itself complete the corresponding business logic, interaction details, HTML and CSS rendering, different styles only through CSS class copy to complete (HTML does not consider, the function of the smallest unit, HTML structure is basically fixed). Then, the superclass component completes the local details function by providing configuration and basic fields to the jsonized local component, and achieves the encapsulation of the superclass component by maintaining and removing the field acquisition method. At the same time, because business functions are concentrated in the parent class, development is only responsible for the basic configuration of components, can easily reuse functions, and then achieve the purpose of business encapsulation

UI AIDS

Secondly, when encapsulation is completed, it is necessary to consider how to promote and how to master low code. So we in the component function after the completion of packaging, the primary consideration is the establishment of the document system and UI auxiliary tools. There are many available on the documentation web, and mature document translation tools reference all UI architectures.

Assistive tools can be a little bit more self-explanatory, and I think assistive tools can be biased towards shortcuts, towards visualization.

For shortcut function is given priority to, I think such a question, the same functional unit, the programmer will want to use some of the same or get to know each other’s name (such as form, form, button) to let others understand what they are fast, for these good units, good name often is what we call named code specification, Then can we use the names of these specifications as shortcut keys so that users can quickly develop the code and advance the team specifications by remembering the shortcut keys?

Jsonized components can then be used as the basis for visual development or low-code platforms, and it’s much easier to drag and drop a JSON or configure a PAGE than to implement them directly.

It is necessary to build the front and back end interactive tools

Having solved the problem of encapsulation and strengthened itself, we have to face the optimization of team problems. In fact, the front-end development environment in Chengdu is very bad, and most teams have not realized the separation of the front and back ends at all. Most people know, separation before and after the end, that is what cause they were coupled together, at first, the former ajax era, most of the rendering, the server through the server language, binding the data directly, front and back side is often a person is doing, then with ajax, had the juqery, data binding by side forward step by step, but bound more difficult, Juqery is mostly responsible for page effects; In MVVM was born later, data binding is the first difficulty is reduced, interactive logic of mass transferred to the front page, the official start of the before and after the end of the separation, but it is still not enough, because after separation of the front-end is based on the front-end interface data, according to the interaction and interface cannot advance design, development, front-end to the back-end still have rely on, And has been in the back-end development to complete the downstream, can not be parallel development, and then lead to a series of problems, such as: front-end to back-end testing; Back-end interfaces are constantly changing, resulting in a disaster of front-end functions. Even if the interface document represented by Swagger is implemented, the front end still faces no interface data to support interaction details verification, and the interface cannot be found quickly in the document. Moreover, at the end of front-end encapsulation, most of the field configuration comes from the interface, most of the interaction is based on the interface field structure, and most of the interaction details are based on the structure encapsulation, and most of the configuration fields can be generated according to the back-end interface document.

Therefore, to solve these problems, it is necessary to build an interactive tool with interface management, mock interface, configuration field generation and other functions