takeaway

Low code is undoubtedly a hot topic in recent years, the author had a low code development experience before, or have some experience. Recently, I had some opportunities to sort out my previous experience to facilitate my construction of a complete system. Since there is not a system before the article, so the series can only be regarded as a “ramble”, more think of where to write. I also try to control the length, so that each article can stand on its own, and each article can be put together to form a whole.

In addition, the problem of professional ethics, it is not convenient to reveal too many details, so it is more based on theory, to provide a strategic selection direction, please forgive me.

The body of the

Changes brought about by the three front-end frameworks

In “Writing Functional Programming Code That A” Fool “Can Understand,” I made a point:

In addition, from the current popular three frameworks, have gradually “data”. React as an example, its abstract idea can be simplified as UI = fn(state). The DOM operation process is shielded by means of VDOM, DIFF, JSX, etc. The mapping between state (pure data) and UI is realized. The impact will not be expanded.

The vast majority of front-end development today is dealing with data (state), rather than directly dealing with the DOM as Jquery did before.

MVC or MVVM means that the current front-end framework is perfectly decoupled from View, logic, and State (Model). When we write code, we just bind a property of the component to a value of state, and we don’t need to worry about anything at the view level. All that’s left is how to manipulate state, which is fn in UI = fn(state). Obviously, it’s essentially a function, and it’s a pure function.

Speaking of which, I’d like to introduce you to a library, Google Blockly, that allows you to create an executable function by dragging and dropping it from a web page. Yes, is now the children’s programming training that set of things, the author even guesses that many children’s programming actually use blockly.

Back to the main point, on the front page of Blockly, we can see that JS code can be generated directly on the right side by dragging and dropping. Again, JS function code can be generated directly by dragging and dropping. That means we’re a third of the way through the problem of low front-end code, which is a bit of a shock to say, but I’ll expand on it a little bit.

Low code genre

There are two main schools of low code that I know of, and one is called form-driven. The first step is to create a [form] by dragging and dropping. According to the field structure of the form, a [data structure] or data model can be created. At the same time, CRUD of data can be created. I’m not going to analyze it because I don’t have enough space, but you probably know how to do it.

The other is called model driven. Unlike forms-driven, the first step is to create a [data model], which can be simply analogous to creating a database table and having the CRUD of that data. This data can then be bound to forms, tables, charts, or as input to some invisible scheduled task.

You can get a sense that forms-driven is more in line with the thinking of the average non-developer, and model-driven is more in line with the thinking of the developer. As a code farmer, the author is of course more familiar with the latter. Model-driven implementations fall into two categories.

One is that when the APP is executed, the page and data model are rendered in real time. That is to say, we need to develop a [runtime parsing engine] to parse the APP model data generated by dragging and dropping in real time. I call this the analytic type.

The other is to drag and drop the APP model data and directly compile it into front-end code. The final product is JS, CSS and HTML, which is exactly the same as the product we usually write code. I call this compiled.

Of course, form drivers can be implemented using either of these types, but they are generally implemented in a similar analytical way. After all this detour and introduction, it’s time to get back to the point.

The main reason I chose the model-driven compiler approach to low code implementation is that if code is generated, it can theoretically leverage greatly from the existing development ecosystem. As an immediate example, if we can generate the source code for React or Vue, we can use existing libraries such as Taro or Uni-app to achieve cross-platform goals. It’s also easier to integrate custom code.

All I have said is that I want to generate code that looks exactly like what we normally develop by visualizing drag. And for the sake of focus, this article focuses only on front-end low code.

Visual generation of data model

It has been analyzed above that visual drag and drop of view, data and logic is needed to achieve low front-end code. At present, blockly can realize logical JS function code generation in theory. Let’s look at the other two.

JSONSchema is a type of data used to describe and validate JSON. It is officially defined as follows:

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.

Here’s an example:

JSON Schema

{
  "$id": "https://example.com/person.schema.json"."$schema": "https://json-schema.org/draft/2020-12/schema"."title": "Person"."type": "object"."properties": {
    "firstName": {
      "type": "string"."description": "The person's first name."
    },
    "lastName": {
      "type": "string"."description": "The person's last name."
    },
    "age": {
      "description": "Age in years which must be equal to or greater than zero."."type": "integer"."minimum": 0}}}Copy the code

Data

{
  "firstName": "John"."lastName": "Doe"."age": 21
}
Copy the code

Therefore, it is appropriate to use JSON Schema to describe front-end data in theory. In addition, as shown in the figure below, Yapi has actually realized the function of visually generating JSON Schema, so we have basically solved the data part.

It is worth mentioning that, after all, JS has fewer data types than other back-end languages, so it cannot be directly mapped to other languages. However, it is not too difficult to solve the problem, just like the idea of JSON Schema extension data type.

In addition, using the idea of ER diagram to build data model is also a good choice, after all, is a veteran of the software development field.

Visual view generation

This is the biggest part, and the main difficulties are as follows:

  1. How to implement drag and drop technically, and the overall interaction;
  2. How to implement binding with data model and logical controller;
  3. Theoretically, components are infinite. How to formulate a format specification to decouple development and integration of components like plug-ins?
  4. How to generate source code.

Due to the lack of space, I plan to write another article, the link will be added later, please bear with me.

conclusion

The author abstracts APP as: APP = UI (interface) + Data (business Data) + Logic Control (Logic Control). In addition, Access, as a special kind of data, can be singled out as it relates to all three parts. This idea is essentially the same as MVC, MVVM and other model abstractions. In terms of the separation of the front and back ends, the front and back ends have their own MVC model. For the back end, the whole front end belongs to V in MVC; For the front end, the whole back end is just M in MVC. Understanding this abstract relationship is very key, is the key of the key, the author temporarily can not think of the appropriate analogy to describe this relationship, so can only emphasize the importance here, and then let the students understand.

In the future, I plan to fill the front-end low code view part, complete the front-end low code, and then the back-end low code, and finally may fill some permissions, publishing, compilation and other corners, please look forward to it.

“Reading makes a full man; conference a ready man; writing an exact man” — Francis Bacon