preface

In recent years, Lowcode and Nocode are very hot topics, and teams of major factories have also developed many similar products. From visual construction to visual logic arrangement to front-end intelligence, these have brought revolutionary improvement to front-end research and development efficiency.

A lot of front end students see the front end of intelligent nouns on the psychological resistance said: “front end intelligent is really ‘revolutionary’, change a lot of front end students life, let a lot of front end unemployment.” In fact, the emergence of such products is essentially the same as building tools, CI/CD, automated testing, component libraries to improve front-end development efficiency, reduce boring and repetitive work.

The cycle of LowCode and NoCode

In fact, lowcode, NoCode is a perennial topic. Front-end as early as more than ten years ago, there was a page visual construction tool like Dreamweaver(hereinafter referred to as DW), but to today’s work has no one to use it, the main reason is that the current data and the structure of the page has been completely separated, we need to send network requests to render data in the page. DW became a thing of the past because it couldn’t carry a lot of dynamic content, but this kind of thinking continued and teams developed many similar platforms. This allows non-technical people (operations, product managers) to participate in application development.

Ideal is full, reality is very skinny. NoCode is more suitable for vertical scenes. Unlike LowCode, we can make up the deficiency of materials and D2C through coding. At present, only about 7-80% of the product can be developed through NoCode. But to think from another Angle, it is possible for a non-technical person to complete an MVP version of the product with a very low threshold, which can be quickly put into the market to verify the team’s goals, quick trial and error. If the verification is feasible, continue iterative optimization by converting to LowCode or ProCode.

In fact, this approach has already been implemented in game development, with Visual Scripting editing available in all major game engines, such as UE blueprints and Babylonjs’s new Graph Editor (shown below). Current mainstream games such as PubG and Fortnite were developed using Visual Scripting at the beginning, and then switched to code development after proving the feasibility of the solution. The pace of development of some front-end applications in the future may also be NoCode => LowCode/ProCode.

D2C

D2C is short for “Design to Code”. As the name implies, it is to generate Code from Design draft, which is a very important concept in front-end intelligence. As early as 2018, BEFORE I entered the front end, I heard that 70%+- of the code of a Bao Double 11 event was generated by AI. Obviously, this is not such a new technology. In fact, Photoshop has supported exporting design drafts to HTML codes more than a decade ago, but due to the unfriendly layout and the inability to bear dynamic content, It is not widely used. However, with the development of Web technology, only generating HTML+CSS can no longer meet our needs, more hope to generate DSL such as Vue, React, miniApp, we can do secondary editing.

In recent years, there have been tools like ImgCook and CodeFun that generate page sections of a mainstream DSL using Photoshop, Sketch, and images. We just need to focus on the business logic and don’t have to align with the UI. Thus helping us improve the efficiency of development and communication, we can put most of the energy into JS logic. But at present, the D2C tools restore degree and CSS part of the reuse degree have a lot of room for improvement, some cases also need to manually adjust the style, look forward to their early maturity.

In the future, front-end intelligence will not only include D2C, but also Product to Code (P2C), which means Product document generation code. Product managers only need to write Product requirement documents to generate codes based on AI. There is currently a similar demo in the front-end community: GPT-3, where we can see that JSX code can be generated for us with a simple text description. In fact, some domestic large factories are also exploring the application of P2C, looking forward to their early maturity, after all, the use of P2C is the most simple and intuitive, of course, the research and development cost behind P2C is also very high, we can boldly imagine when the mature ~

API2code

The part of the page can be generated through D2C, so we can’t help thinking, can we also generate the API part? We can think back to previous projects. We also need handwritten request methods and API paths, especially in Typescript projects where apis have a lot of interfaces, we define field types when we define documents, When writing code, you still need to write field types by hand according to the API documentation, which is too much. As with the front end, the back end also needs to write a set of types manually. This creates a lot of repetitive work, so we can build a tool to generate code. So I and the big guys wrote a CLI called Fe-code, which is used to generate front-end API CRUD and type code from the documents of various API management platforms.

Earlier this year, Yu said in a live broadcast that “there are a lot of front end teams working on front end type unification in the international environment

Currently, the CLI supports converting OpenAPI’s JSON Schema and custom JSON structures into JS, TS CRUD code, and interfaces. We have also opened up parser options.

const parserMap = {
  Custom: apiConfig= > apiConfig, // Internal custom data structure
  OpenAPI: apiConfig= > parseOpenapi(apiConfig), // OpenAPI
  // Other API specifications...
};
Copy the code

You can write the conversion function according to the JSON Schema of your team’s API management tool and convert it into fe-Code’s internal custom data structure. Finally, the code we need will be generated through this custom structure.

Take Yapi as an example (each API management platform provides a method to export JSON Schema). We can choose JSON from project -> Data Management -> Data Export and finally export JSON. We can convert the JSON write conversion function to fe-code’s internal custom JSON Schema.

Fe – code to use

You can install fe-code -d by NPM. You can also use the NPX command directly

We can use the generated parts of the API code directly through NPX fe-code API2code. NPX fe-code e2c to initialize Vue/React + Webpack/Vite /Snowpack if the new project doesn’t have scaffolding.

To use api2code, we need to pass in two paths with arguments -ijson Schema. The output path of the -o generated code is as follows :(example JSON)

npx fe-code api2code -i ./apiConfig.json -o ./api
Copy the code

Prettier is used for code formatting. By default, prettier is used in the project directory, and default is used if there is no prettier configuration. The generated code is as shown below. The following code is the CRUD for TS, and we can see that in the reoutput directory there are two folders, models and Services, corresponding to the data type and API request respectively. There are no models if you choose JS.

Just like the above, we can generate types and CRUD code from API with simple commands, which greatly improves our development experience. We no longer need to copy types from API documents one by one, and also reduces the probability of error. We can focus more on complex business logic and code quality.

GraphQL

The previous section only described RESTful code generation. Here is a brief introduction to the GraphQL code generation library. There is already a mature product in the GraphQL community: GraphQL-code-Generator. We can generate not only type code but also react-Query, react-Apollo, Node, Java… Support for dozens of languages/frameworks/libraries.

Visual construction

Visual build this topic must be familiar with it, we just need to drag and drop the way to generate applications or edit again (Lowcode). Such platforms have been around for a long time, and there are similar products in various front-end teams. At the same time, many companies are offering external services that allow companies to develop websites or event pages without front end engineers. Currently fe-Code is in the 1.x version, we are considering introducing UI interface in version 2.0 to make all the above commands into visual operations, and introducing visual construction. We are considering providing and managing materials commonly used in business through storybook+Bit, and agree a set of specifications to open to all developers. Allow other developers to contribute materials as well.

Consider developing the whole visual building part by means of Electron or Chrome File System Access API. After dragging and dropping the building part, the component code can be written into the directory associated with the project page and formatted according to user-defined configuration. And it can be associated with the upstream parts of the API2Code to inject data directly into the component. At this point, we can use tools to generate 60-70% of the project code, reduce repetitive work, say no to overtime, and spend the rest of the time with NPY how much better 😁.

Blueprint for the front end

With the advent of the big front end, front-end engineers became more than just page (component) writers. Front-end engineers became a cross-cutting position. A few years later, when the front-end intelligence is fully mature, the development of some simple requirements does not need human code. We can completely free up the time used to write repetitive and boring code and devote it to more interesting fields such as XR, graphics, AI, webIDE. The arrival of 5G will certainly bring unlimited possibilities to their front-end applications.

If any errors are found in the article, feedback and correction are welcome.

Write in the last

Open source address: Fe-code, welcome to star⭐️, PR.