Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to improve efficiency through business components". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

I. Preface

No matter in the jQuery/YUI era of front-end slash-and-burn cultivation, or to the current React/Vue era based on data-driven UI, materials / components have always been the eternal topic of the front end. Encapsulation based on a large number of repetitive logic can obviously improve the construction efficiency of the front-end UI, simple and direct, so no matter how the technology stack changes, the material work is arranged in the first place of each front-end team.

In 2021, the basic component architecture based on the React/Rax system has been basically improved, including AntDesign [1] of Ant good Design language, and Fusion [2] (Alibaba background UI solution, open source) quickly customized by the Group based on DPL. The function at the basic component level is becoming more and more perfect, and the low-level repeated construction at this level among various business teams is becoming less and less, which is a very good result. However, in the construction of business component system, there is still a situation of letting a hundred flowers blossom. Due to the continuous expansion of technology stack (visualization, Mini Program, etc.), there are still many problems in the development of business components, such as engineering system confusion and development link failure.

In the more than 5 years since I came to enterprise intelligence, I have experienced the team material system from the initial Arale/kuma, to the react-component-based UXCore/SaltUI, and then to the full integration with Fusion now. Changes at the fundamental level have also brought about constant changes in the tool chain in the area of business components.

1. Dilemma

One day, colleague A came to me and said that TA business needs to build a business component package, including the PC side, Mini Program and the corresponding visual components. At that time, I was doing some work on the front-end business capability building, so I wanted to ask for my suggestions. This problem seems to be very simple, but in practice, it is found that there are many problems.

First of all, the business components of PC were developed using Flying Bing [3] (iceworks, Ali GUI construction tool) + deep scaffolding template (deep comes from the enterprise intelligent user experience team). The advantage is that it can deeply communicate with Fusion, and it is convenient to publish and synchronize materials to the corresponding deep site of Fusion. Mini Program / mobile components, at that time, Rax-based dynamic Mini Program component solutions Fusion Mobile and Deep Mobile were just in their infancy, and the development of business components did not have their own standard, and the only set available was the gdt-utils made by the front-end team that had previously been pinned down by government affairs.

The visualization component is the vdev tool chain provided by Lego (Ali Enterprise Visualization platform) team. At that time, another problem was that because the PC end was based on the React framework, while Mini Program / mobile was based on the Rax framework, visual development could not complete the development of PC and mini programs by initializing a package.

To sum up, to develop a business component that covers three modes, you need to adapt and learn three tool chains, initialize four packages, release four npm package, and in subsequent use, users need to remember the four package names and their corresponding usage scenarios, and see how they are used in at least two places. At the same time, in the maintenance phase, the similar model, request and data processing logic of PC and mobile can not be reused. What if we want to reuse? I'm sorry, you need to send another toolkit to transfer between several packages. All these virtually increase the cost of developing a business component, and the students' energy is consumed in the process of these frameworks, packages, and co-tuning.

two。 Integrated development

Although it is possible to complete the development in this way, it is really not satisfactory in terms of starting threshold and development efficiency. One is that a lot of documents need to be written to clarify the matter, and the other is just to develop a business component. Is it really a good solution to need such a large cost? Is it possible not to need so many things, just one tool chain and one package to solve all the problems? isn't that good? Good is good, but there are a lot of problems to be solved before we really do this.

The biggest problem is how to combine Rax and React frameworks into one tool chain. This does not seem to be a difficult problem, it seems that as long as the previous React and Rax webpack configuration to run separately, but after the integration of some things are synthesized, such as demo files, for a student who wants to integrate development, naturally do not want to write several copies of almost the same demo, just because different operating frameworks bring different references. Similarly, there is the prototypeView file in the visualization component, which is used to render the component in Lego designer. Here you need a little knowledge of Lego component development. The approximate code composition of the prototypeView file is as follows:

This kind of design is designed under the premise that the visual components are all React frameworks, and there is no problem in the past practice.

However, after fusion development, just like the comments in the above code, there needs to be a solution to how to drive a React component and a Rax component to be mixed and packaged and can render normally. Secondly, from an engineering point of view, which tool chain is selected to achieve this integrated development capability? Obviously, each of the current tool chains does not have the ability to achieve directly, is it to choose one of them to enhance, or the ability to combine the three? Each has its own advantages and disadvantages and needs to be weighed. Another point that must be considered is how to minimize changes to the original mind of the developer, and try to keep the matching of Fusion material capabilities (such as synchronizing to the Fusion site), so that developers can migrate to the new development model with as little cost as possible. After identifying these problems, we began to solve this development dilemma through integrated development.

3. Begin to solve the problem

Determine the directory schema

First of all, we need to determine the directory structure of the fusion package (later referred to as the "fusion package"):

From the source structure, we basically follow the file structure of visual components, which on the one hand meets the special requirements of visual components (such as configuration of setters, design rendering, etc.), on the other hand, through the formulation of the main field of package.json, we can also directly reference the package name to call the component.

The technology stack fully uses ts and scss, aligns with Fusion components, and facilitates the use of scss variables and css variables.

In the construction product, we combine the characteristics of several tool chain products, first build the babel translated es5 file and the corresponding declaration file for general projects. Secondly, the esmodule of reserved import/export is built, which is used to do treeShaking for projects with requirements for package size. Then, the corresponding md is built into a demo that can be directly previewed by the browser and placed in the build folder to align with the Fusion components, and then copy the files under the lib folder to the build directory for easy construction and identification of Lego (when Lego builds, it will directly look for files such as view.js and view.mobile.js under the build directory).

Selection of tool chain

In the choice of tool chain, we finally choose Lego's development kit vdev as the base to expand, this consideration is that the whole development system of visual components is heavy, and not plug-in, and the cost of extraction and migration is high. Second, compared with the other two tool chains, vdev maintains in the infrastructure department of a large team and is relatively easy to communicate and collaborate. The rest is not completely rebuilt, but we reuse plug-ins under the existing build-scripts system as much as possible. First of all, we modified vdev to support the call of build-scripts-related systems, and the rest of the development started based on plugin under build-scripts. The final link is as follows:

The pc.json is roughly as follows:

At the time of development, we laid down a principle. Based on the preview of PC, Mobile and Mini Program under the general rules, we try our best to implement it through the official build-plugin-component, while the special rules for the fusion package, such as special configuration handling required for fusion, file transfer after construction, and so on, are implemented through co-building or repairing unsupported functions or bug. Through the post-order plug-in under the build-scripts system (we call it build-plugin-vdev-component here), we can further deal with the configuration defined by the pre-order plug-in to add features. This not only reduces the follow-up maintenance costs, but also helps more business through build-plugin-component.

After determining the basic architecture, I further defined the npm scripts related to the fusion package:

Start: used to start debugging in the visual part, including designers and previews

StartPC: used to start debugging of the PC part

StartMobile: used to start the debugging of the mobile Web part

StartMiniapp: used to start the debugging of the Mini Program part of the mobile

Build: used to generate the build artifacts mentioned above

Except for start, all the others rely on build-scirpts plug-in system to complete.

The main problems solved by debugging

Once the general framework has been determined, it is necessary to start the specific development process. The process related to start does not need to be modified much, mainly to alias the component name to the corresponding entry (PC to view.tsx, Mobile to view.mobile.tsx), and the rest is mainly to complete the missing features in build-plugin-component, such as support for scss and inlineStyle configuration in the Rax section. One point worth mentioning is the handling of jsx in demo files. We all know that jsx is the enhanced syntax of js proposed by React, which is used to describe templates completely using js syntax, which is actually not directly recognized in browsers. The general way of processing is to convert babel to the corresponding transformation syntax, such as

Convert to:

For example, jsx tags will be converted to React.createElement ("div"). This is fine under a single framework, but since demo in the converged package is reused on PC and mobile, is it converted to React.createElement or Rax.createElement? Obviously, it is not very appropriate, he can only decide when starting and debugging PC or Mini Program, and the more recommended writing method for Rax officials is not to directly refer to the full amount of Rax variables, but to load the corresponding api from Rax variables on demand, such as createElement, which is naturally different in writing. So we take an intersection in the way the demo file is written, roughly as follows:

The demo file is written from the perspective of PC, and the references depend on react's Component and createElement, as well as the basic component library @ ali/deep. When starting Mini Program debugging, react alias to rax, @ ali/deep alias to @ ali/deep-mobile. And jsx-related, such as will be converted to createElement ("div"), which ensures the feasibility of compilation from the writing.

Build the main problems to be solved

In the process of build, because we want to build the demo of PC and Mobile at the same time, and build-plugin-component can only start the construction of Rax or React, this obviously does not meet our needs. If the script is called twice, there are a large number of repetitive operations, such as adding and deleting folders, and so on. We chose to use the rax part of build-plugin-component, add another webpa ck task of React in the post-order plug-in build-plugin-vdev-component, and complete the demo construction of PC and Mobile at the same time.

In the construction of es5 files, also encountered jsx compilation problems, because the source code contains part of the react file also contains a part of the rax file, in start, you can also follow the entry chain to set the babel configuration, but build on the source file only babel there is no webpack, so to use other methods to deal with. Our approach is to first analyze the AST of each file, analyze whether the file is a React or Rax component from the file's package reference, and then compile with a different babel configuration. Why isn't it handled in the same way as in demo mentioned above? The reason is that the way of demo is strongly dependent on the introduction of createElement, and the way it is written is limited. In the part of the source code, we hope to give users a more flexible way to use it.

Basically, all scenes under ProCode can be used normally, but not in Lego environment, mainly in the processing of prototypeView.tsx file. As mentioned above, this file introduces both React and Rax components. Although in the design state, only one of the components is actually rendered, some API is used in the declaration of component classes, such as Rax.forwardRef. This results in an error that cannot be used in the design state because of the lack of API without any processing. While Lego components save builds, and regular Procode projects, each component is built separately, and the components are built without knowing whether they are going to be used in Lego PC (React environment) or Lego Mini Program (Rax environment). So we generate an extra prototypeView.rax.js when we build the component locally. There is no essential difference between the content and the built prototypeView.js, but it provides Lego packaging to build an additional entry. When Lego builds detects that it is a fusion package, different webpack alias is configured for the entry of the two files. In prototypeView.js, the api alias related to rax will be added to the rax-compact package of the remaxjs community. Used to display the design state of Lego PC version (React environment). Api alias the react related api alias to rax/lib/compact in prototypeView.rax.js for the display of the design state of Lego Mini Program (Rax environment).

4. Final effect

Finally, we unify the development and use of business components into one package (integrated vc package), a tool chain (vdev: initialization, debugging, release), and implement on-demand loading and compilation of the two basic component packages @ ali/deep and @ ali/deep-mobile (also supports Fusion/Antd). When using it, no matter the PC side, Mini Program or visual part, you can reference the same package, so there is no need to remember different package names and their corresponding platforms. Normally, we can introduce the PC part by referencing the package name directly and the mobile / Mini Program part through es/view.mobile (or lib/view.mobile). In addition, we have registered the corresponding entry in package.json, so that we can configure it through webpack resolve and refer to the mobile part directly through the package name.

Is it possible not to do the repetitive process?

1 dilemma

The first version of the integrated development solves the mental problems of developers in project maintenance, release and use of packages, and is of great help in the logic of PC and Mobile reuse. However, developers still have a lot of repetitive work in the development process. For example, although there is complete ts support and interface declaration, users still need to configure the setter of the component. The process of configuring the setter component is mainly to specify the properties, default values and types corresponding to the setter. For example, after the component is released, you also need to go through a set of resident mechanism to view the Demo for yourself and others in the material center. For example, Mini Program debugging, each time you start the build locally, but also open the Mini Program's IDE. These are every business component development have to do, but basically repetitive work, all repetitive things are regular, can these repetitive things not be done?

2 automatically generate prototype.tsx

As mentioned earlier, the development portal files of PC and Mobile in the fusion package have been fully ts and templated. The entry files are roughly as follows (PC entry view.tsx is shown here, and Mobile is similar to this):

Through AST analysis, we can locate all interface statements as well as defaultProps statements. Typescript lint requires that there is only one Class declaration in a file, coupled with Component's ts generics, these prerequisites allow us to navigate to the interface of props to get the name and type of each prop. Considering that the most important purpose of business components is to be quickly used in Lego, there is no need to map each type and default value in special refinement. We can find the corresponding setter for the base type, specify a JSONSetter for some complex types, ActionSetter for the render function hook, and events for the callback event. The template file of prototype.tsx is also a relatively standard way to write, so we can easily analyze the defined properties through AST, these attributes do not need to be added again, and the location of the new property code is inserted. By directly generating this part of the setter code, our components can basically be used normally in the designer without modification (that is, various properties can be configured. Fluently use the various functions of the component, not just the presentation).

3 release automatic synchronization material center

Component release is only the first step. Only when a business component can be found and the document can be read is the beginning of component services. In enterprise intelligence, we now uniformly use the material center to display components. In the past, business components can only be put on the shelf to the material center through the backstage configuration of the material center. this process requires a lot of manual filling, which is time-consuming and labor-consuming. After the components are released to tnpm, vdev collects the necessary information on the shelf, such as components owner, components belonging to business areas, the end of component adaptation, etc. Material center provides API call to synchronize these information directly to material center to achieve the effect of one-click release + material center on the shelf. Of course, this synchronization is not mandatory, and for some beta versions, you can choose not to synchronize.

4 Mini Program WebIDE debugging

The original Mini Program debugging must build a local project directory in line with the Mini Program structure, and then use Mini Program IDE to open the corresponding directory to start debugging. This process spans multiple tool chains, and the learning and operation costs are relatively high. It just so happens that the Mini Program team of Alipay has launched the @ ali/mini tool chain, which can be debugged by launching a Lyra browser simulator based on the next click of the project directory. Our integration package also integrates @ ali/mini. The configuration files needed by @ ali/mini are automatically generated by component developers. With a command, you can start WebIDE directly for debugging.

How to simply develop / use a component with services?

1 dilemma

In the above two parts, we mainly focus on the development of a pure UI business component, but we also know that many business modules need to be used together with back-end services to fully express a scenario. The simplest example is a person search component. If you do not match a service, it is a selection component with a special list style.

In the past, there were two strategies for such components, one is to match a cross-domain jsonp interface, but with the current tightening of security, there are fewer and fewer such interfaces. The other is to match a business interface, but this kind of interface and component joint debugging is very troublesome, because the interface can only be used under the business domain name. Because of this restriction, there are two different ways of thinking. One is to make a page on the business domain or simply transfer it in the business project. What is more, the front end directly sets up the back-end service to tune locally. It feels very troublesome to think about it. The new student who took over estimated that it would take a long time just to set up an environment.

Another strategy is to debug the front end using the interface or data of mock. This kind of environment is relatively simple, but it brings a lot of co-debugging costs. First of all, it is difficult for the mock interface to simulate the real data online, and secondly, who keeps the interface consistent with the online, which brings additional workload. It is not convenient to develop and use. Because the interface is owned by the business itself, when debugging is started locally or in Legol, the interface cannot be tuned, so it can only be deployed to the business page to see the effect. Or if you choose a component that does not carry the service by default, and then match the corresponding interface when you really use it, you will find the interface with the component. There are many forms of the interface itself, and there are different ways to run it. It will take a while to really use it to see the effect.

2. Service call

As can be seen from the above analysis, the main difficulty of such components lies in the invocation of services, and local development is difficult in the absence of cross-domain request interfaces. Therefore, the core problem is to provide a class of services that can be easily invoked locally or in Lego environment without worrying about security issues (data leakage and pressure from service providers, etc.). This requires an API gateway, which can solve the authentication of service calls and protect service providers. In the case of a gateway, the next step is to solve the problem of how to call local and Lego. Lego call is relatively simple. Lego itself has a back-end service and only needs to provide a process. When a user accesses a component and service, go to the gateway to automatically apply for daily service invocation. Because most daily services have been desensitized, and isolation from real data can not be directly used in production. Therefore, the subscription application and approval of daily services are relatively simple, and this process can be completed directly behind the activation components. Local calls will be relatively troublesome. In general, local debugging starts with a local server (such as webpack dev server, etc.), and it is difficult to call the API directly. There are two solutions, one is that the server provides a daily forwarding interface for cross-domain calls, such as / api/gateway?id=epaas.api.key, and the other is that the server provides a template page, and the front-end server provides js and css, and injects them into the corresponding page, so you can directly request the corresponding interface.

3 practice

In the practice of EI, there happens to be such a service gateway ePaaS to carry the responsibility of the gateway. On the usage side of Lego, we have designed a business capability module to activate the corresponding components and services. EPaaS implements cross-business calls through service subscriptions between applications, so we will let users fill in their own ePaaS before activating business capabilities. In fact, these are not needed for Lego preview. The purpose of allowing users to fill in is to help users complete their ePaaS subscriptions with one click, rather than having to subscribe manually on ePaaS one by one.

Introduction to the function of ePaaS

Of course, ePaaS gateway is not the only choice, we are also actively expanding the access of other gateways.

What else is there in the future? Build efficiency: the above things are only able to do, but it is far from good, especially the debugging commands that are often started, and there is a lot of room for optimization. Each person saves 10 seconds at a time, which adds up to a lot of time.

Go deep into the business: at present, it has been rolled out under some business areas of enterprise intelligence, but it has not been fully covered. This set of things comes from the business, so we should also go back to the business. The boundary scene of the business will gradually lead us into the deep water area.

Business capability: capability is a relatively virtual word. As far as I understand it, it is a collection of services and UI (pages, blocks, components) with an indefinite number of services as the core. Business components with services are our first step in this field, and then we will continue to do in-depth work, including Lego presence of business capabilities, local production of business capabilities, and so on.

LowCode: Lego already has the ability to generate business components with low code drag and drop, but it can only be used in designers with low code visualization. Ideally, it should be able to circulate in various states, but whether it is a business pain point is still being collected.

Model driven? This point raises a question mark because it is only a stage of thinking. At present, the production mode of ProCode, LowCode and model-driven troika has been realized in enterprise intelligence. Business components already have ProCode and LowCode patterns, so can you directly drive UI by binding the model, generate business components through configuration, and reuse them in the business? To some extent, this can also solve the problem of the lack of standard pages that can now be applied to model-driven.

So much for the content of "how to improve efficiency through business components". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.