CN116974527A

CN116974527A - Pluggable page expansion method and system based on low-code front-end component

Info

Publication number: CN116974527A
Application number: CN202311196404.8A
Authority: CN
Inventors: 余辉
Original assignee: Whale Cloud Technology Co Ltd
Current assignee: Whale Cloud Technology Co Ltd
Priority date: 2023-09-18
Filing date: 2023-09-18
Publication date: 2023-10-31
Anticipated expiration: 2043-09-18
Also published as: CN116974527B

Abstract

The invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, wherein the pluggable page expansion method and the pluggable page expansion system comprise the following steps: after the product side completes the development of the page component, the component information is input into the system; the product side inputs open expansion point information which allows the expansion point information to be customized by the project into the system; packaging a front-end SDK on a product side, and loading a front-end component by calling the SDK on a page; the product side registers the back-end interface to an expansion point management center, so that the management center can automatically identify the input and output of the interface and newly add project tenants; sharing interface capacity and extension point definition data of a product side to a designated project tenant, and then acquiring interface capacity of the product side and extension point definition of the product side; the extension point realizes management. The invention is realized through tenant isolation and expansion points, and each item can carry out self-assembly customization under the condition of not affecting the original functions of the product and the customization functions of other items. This greatly improves the customizability and flexibility of the product.

Description

Pluggable page expansion method and system based on low-code front-end component

Technical Field

The invention relates to the field of software development, in particular to a pluggable page expansion method and system based on a low-code front-end component.

Background

Over the past period of time, witnessed a rapid development of front-end development technology. Front-end componentization techniques such as practice/Vue are well established, and complex pages can be broken down into front-end components and then assembled into pages by the components. The lifecycle stages of these front-end components open API control capabilities so that the business side can flexibly control the rendering logic of the front-end components.

At the same time, it can also be seen that, since a software product often cannot meet all business scenarios, different degrees of customization are often required when the project is implemented. However, management methods for customized code have been problematic. Common methods include making a code branch out for customization or writing a different logical branch in the original code by way of if-else. However, both methods have problems, the former causes more and more branches, and synchronization of codes of multiple versions cannot be maintained at the same time; the latter results in more and more complex code logic, which is difficult to update and maintain.

Meanwhile, based on UMD modularized loading technology, some products on the market can achieve that front-end component files are obtained from a server and loaded to pages in running. However, these products often cannot well solve the problem of how to isolate the custom development component from the original product component, which involves the technical problems of visual layout development of the extension front-end component, component loading route addressing, unified management of extension points, and the like.

For example, a project customization developer may not be familiar with the front-end technology of the original product, or the learning threshold is high, resulting in high customization costs. Meanwhile, the custom developed components cannot cover the default components of the original product when deployed, and need to exist in an externally hung mode, but cannot exist in a physical coverage mode. In addition, different projects need to be capable of maintaining own expansion points on line, and the expansion points needed by the respective projects are realized or closed according to requirements.

Accordingly, the limitations of the prior art call for a new solution that effectively solves the above-described problems and provides a pluggable page extension system and method based on a low code front end component.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention provides the pluggable page expansion method and the pluggable page expansion system based on the low-code front-end component, each tenant only needs to pay attention to and maintain own customized functions, so that the communication and coordination cost between projects can be greatly reduced, the personalized requirements of users are met, the stability and the reliability of products are maintained, and the use experience of the users is improved.

In order to achieve the above object, the present invention provides a pluggable page expansion method based on a low-code front-end component, including:

step S1: after the product side completes the development of the page component, the component information is input into the system;

step S2: the product side inputs open expansion point information which allows the expansion point information to be customized by the project into the system;

step S3: packaging a front-end SDK on a product side, and loading a front-end component by calling the SDK on a page;

step S4: the product side registers the back-end interface to an expansion point management center, so that the management center can automatically identify the input and output of the interface and newly add project tenants;

step S5: sharing interface capacity and extension point definition data of a product side to a designated project tenant, and then acquiring interface capacity of the product side and extension point definition of the product side;

step S6: the extension point realizes management.

Further, step S3 includes:

step S31: front-end SDK packaging parameters;

step S32: running a front end SDK;

step S33: loading a remote high-code component js;

step S34: the DSL is operated locally.

Further, step S32 is specifically as follows:

the page calls the front-end SDK:

in the above component parameters, remoteComp is a remote component, url represents a default component path, compxtcode is extension point code, tenant Id is tenant ID, if there is no compxtcode, the resource is returned and operated by using Url specified in ajax request component parameters; judging whether the extension point has custom realization or not according to the extension point code and the tenant ID request background interface if the comppextcode exists, and judging the type of the custom realization if the tenant ID does not return, and adopting a product side default realization;

if a custom implementation is returned, the custom implementation is classified into a high code component and an orchestration component. If the type is a high-code component, returning a js file path, and requesting the path resource to run by ajax; if the type is a orchestration component, a string of DSL is returned, and the low code running engine is invoked for rendering.

Further, step S33 includes:

step S331: initiating a request to a server to acquire codes and metadata of the components;

step S332: loading of component code: after the component codes are acquired, the component codes are injected into the page in a mode of dynamically creating script labels, so that loading of the components is realized;

step S333: component rendering: after the component code is loaded, a component instance is created by using a real.createElement () method and rendered into a page;

step S334: component update: if the remote component has an update, the component code is reloaded and a new component instance is created for updating using the react.

Further, step S34 includes:

step S341: analyzing the structure, the event and the data source part of the page;

step S342: page structure analysis: recursively drawing small-particle components on a page according to the structural data, and uploading parameters initialized by a person;

step S343: event analysis: after the page structure is analyzed, binding the event, and splitting the logic of the event into action instructions of the stripe;

step S344: and (3) data source analysis: the parsing of the data source is independent of structure and event and can be performed synchronously. The data source is ultimately converted into the component parameters for delivery to the interior of the component. Event-operated data source changes may also trigger changes in page structure.

Further, step S6 includes:

step S61: uploading a high-code developed component, and editing and uploading the offline developed component to an expansion point management center;

step S62: a visualization orchestration component: opening a page designer at a project tenant side, dragging a page control, arranging a front-end event, and calling a product side interface to arrange a service component; when the product side is used for registering the incoming interface, the incoming and outgoing parameters of the interface are automatically acquired to participate in the arrangement and development of the component.

Further, version control and rollback functions are also included, specifically as follows:

step S101: creating a version library for the component in the back-end storage system;

step S102: when the component is updated or customized, a new version is stored in the version library;

step S103: adding a version selection and rollback interface at the front end allows the user to switch between different versions.

Further, the method also comprises a preview function,

step S111: adding the function of a preview component in the front-end SDK;

step S112: when a user customizes or updates the component, a preview function is called first, and a preview effect is displayed;

step S113: after confirming that the preview effect meets the expectations, the user performs real customization or updating.

A pluggable page expansion system based on a low-code front-end component is applicable to the pluggable page expansion method based on the low-code front-end component, and comprises the following steps: the system comprises an expansion point management center, an expansion point operation center and a front end SDK;

the expansion point management center is a management center for modularization and customization of product functions, and comprises the following subfunctions:

front end component registration management: allowing the functionality of the product to be split into separate front-end components and these components registered with the management center for selection and invocation during customization.

Component extension point management: the markup product can have open extension points so that custom components can be implemented based on these extension points when the project is customized.

The expansion point realizes management: creating tenant space of each item, and customizing development and management components in the tenant space of each item so as to avoid mutual influence.

Back end interface capability registration: the back end interfaces of the products are registered so as to be multiplexed when the components are arranged, and the parameter entering and exiting structures of the interfaces are automatically identified.

The component development mode comprises the following steps: two modes of high-code component uploading (professional-oriented front-end developer) and component visualization orchestration (front-end developer with general practitioner and skill) are supported.

The expansion point operation center is an independent service and is responsible for executing and managing the customized configuration and functions of each item;

the front-end SDK is used for encapsulating the call of the product side page, so that the call of the front-end component is simplified. The front-end SDK automatically detects whether the component is an expansion point, and if so, the front-end SDK automatically loads the customized component; if not, it will automatically load the default component.

Compared with the prior art, the invention has the beneficial effects that:

1. the invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, which are realized through tenant isolation and expansion points, and each item can be customized by self under the condition that the original function of a product and the customizing function of other items are not influenced. This greatly improves the customizability and flexibility of the product.

2. The invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, each tenant only needs to pay attention to and maintain own customized functions, so that communication and coordination costs among projects can be greatly reduced, personalized requirements of users are met, meanwhile, stability and reliability of products are maintained, and use experience of the users is improved.

3. The invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, which greatly reduce the customizing development difficulty of the front-end component and improve the development efficiency by providing the functions of visual arrangement and DSL analysis rendering.

4. The invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, which avoid physical coverage or modification of project customization function codes on original function codes of products by externally hanging deployment of an expansion point operation center, thereby protecting the independent integrity of the original functions of the products.

5. The invention provides a pluggable page expansion method and a pluggable page expansion system based on a low-code front-end component, which support personalized front-end customization of standard products in a hot plug mode and provide high operation and maintenance efficiency and convenience.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will briefly explain the drawings needed in the embodiments or the prior art, and it is obvious that the drawings in the following description are some embodiments of the present invention and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of the present invention;

FIG. 2 is a functional diagram of the system of the present invention;

FIG. 3 is a schematic diagram of an implementation of the present invention for isolating project extension points by tenant;

FIG. 4 is a schematic diagram of an extension point operation center deployment configuration;

FIG. 5 is a front end component auto-addressing diagram;

FIG. 6 is a diagram of a call front-end component using a front-end SDK;

FIG. 7 is a process diagram of a local loading of a remote high code component js;

fig. 8 is a diagram of a locally operated DSL;

FIG. 9 is an extension point operation center deployment diagram.

Detailed Description

The technical solution of the present invention will be more clearly and completely explained by the description of the preferred embodiments of the present invention with reference to the accompanying drawings.

As shown in fig. 1, a pluggable page extension method based on a low-code front-end component includes:

step S6: the extension point realizes management.

As a specific embodiment, it also includes adding version control and rollback functionality, when a custom component becomes problematic after a certain update, it may be necessary to rollback to the previous version. Thus, adding version control functionality will greatly enhance the robustness of the system.

The implementation steps are as follows:

creating a version library for each component in the back-end storage system;

each time a component is updated or customized, a new version is saved in the version store;

adding a version selection and rollback interface at the front end allows the user to switch between different versions.

As a specific embodiment, it also includes the addition of a preview function, with a preview step to help the user confirm that their changes are expected before the component is customized or updated.

The implementation steps are as follows:

adding a function of a preview component in the front-end SDK;

when a user customizes or updates the component, a preview function is called first, and the preview effect is displayed;

after confirming that the preview effect meets the expectations, the user performs real customization or updating.

As a specific embodiment, as can be seen from fig. 2, the system is composed of an extension point management center, an extension point operation center and a front end SDK. The method comprises the following steps:

1. expansion point management center

Front end component registration management: the product breaks the page function into individual front end components from which the page is assembled. The front-end component which is detached is registered in the expansion point management center, the component capability is indicated to be accessed to the management center, and the component capability can be selected and invoked when the subsequent page customization visualization is arranged. The multi-environment configuration is supported, the request paths of the front-end components of the development/test/production environment are respectively configured, the front-end components can be stored on any server, and the component files can be requested according to addresses in running.

Component extension point management: the check-in product allows open extension points for which own components can be implemented when representing item customization.

The expansion point realizes management: and creating tenant spaces for different projects, wherein each project customizes development and management components in the own tenant space without affecting each other. The project can inquire the expansion point of the appointed product, and can select to turn on the customizing switch, and then customize the project in the following manners: uploading components of high code development and submitting components of visualization orchestration. If the expansion point is not needed any more and can be closed, the original default capacity of the product can be restored after the expansion point is closed.

Back end interface capability registration: when a front-end component is customized, most of the interface capacity of the back end can be reused, the back-end interface of the original product can be registered in an expansion point management center, and the input and output structures of the interface can be automatically identified, so that the input and output of the interface can be acquired to participate in the arrangement and development of the component when the component is arranged.

Component development mode 1-high code component upload: following umd modular loading techniques, a component is developed using conventional high code programming. This approach is primarily directed to professional front-end developers.

Component development mode 2-visual orchestration of components: opening the page designer, dragging the control, arranging the front-end event, and calling the interface service to arrange a business component. This approach is primarily directed to front-end developers who are general in practitioners and skills.

2. Expansion point operation center

Importing tenant configuration data: the deployment of the product is carried out in the original self mode without any adjustment. If the project is customized, an expansion point operation center is additionally deployed, customization data of the project is exported from the expansion point management center and then imported to the expansion point operation center, and when the product page is operated, customization capability provided by the expansion point operation center can be called. When the same product is used for coping with different customizations of different projects, only customization data of different projects need to be exported and imported to an expansion point management center.

Extension support service: the page SDK requests the service module, judges whether the expansion point has expansion realization, and acquires DSL characters of the coding component or JS addresses of the high-code component.

3. Front-end SDK

The front-end component invokes the SDK: and packaging and front-end SDK, and simplifying the call of the page. The product side page calls the SDK to complete the call of the front-end component.

The front-end components automatically address: the front-end SDK automatically detects whether the component is an expansion point or not, whether the expansion point is custom-made or not, and if yes, the custom-made component is automatically loaded; if not, the default component is automatically loaded. When the customized component is loaded, whether the component is a high-code development component or an orchestrated component can be distinguished, and if the component is the high-code development component, the component JS is loaded from the expansion point operation center; if the DSL character is the arranged component, loading the arranged DSL character from the expansion point operation center, and dynamically analyzing DSL character at the front end to complete the rendering of the component

As a specific embodiment: and isolating the realization of each project expansion point according to tenants. As in fig. 3.

Step 1, front-end component registration management: the product side enters the information of the components after the development of the page components is completed, wherein the information comprises the names of the components, the codes of the components and the request address (supporting the development/test/production multi-environment address).

Step 2, component expansion point input: the product side inputs the open expansion point information allowing the customized realization on the project of the product, and the method comprises the following steps: component name, component code, extension point name, extension point code. Each extension point binds a component code (i.e., registered in step 1 above) that indicates that the standard function of the product is to display the component, and if not customized on the project, the default display loads the component.

Step 3, calling the front-end component by using the front-end SDK: and packaging the front-end SDK on the product side, and calling the front-end component by using the SDK on the product side.

Wherein step 3 has a plurality of steps as shown in fig. 6.

3.1 Front-end SDK encapsulation parameters. Which itself is also a component, provides for direct invocation of pages, and receives the following parameters

Parameter encoding	Party name	Description of the invention
			url	Default build path	Must default loaded addresses if the component is not customized
compExtCode	Extension point coding	If the component needs to be customized, it is not necessary, a unique extension point code generated by the management center,
			tenantId	tenant ID	Optionally, if the component is implemented by multiple customizations, mapping to a specific implementation based on tenant ID

3.2 Front-end SDK core run logic

The page calls the front-end SDK:

in the above component parameters, if the combxtcode does not exist, requesting the resource designated by url in the component parameters to come back and run by using ajax; if the combpextcode exists, judging whether the extension point exists a custom implementation or not and judging the type of the custom implementation according to the extension point code and the tenant ID request background interface. If this tenant ID is not returned, then a product side default implementation is employed.

3.3 Process for local loading of remote high code component js

Wherein the 3.3 step has multiple steps, as shown in fig. 7.

The remote high-code component js file is also written by means of compact, and the loading process of the code after construction is as follows:

3.3.1. and initiating a request to a server to acquire the codes and metadata of the components.

3.3.2. Loading of component code: after the component codes are acquired, the component codes are injected into the page in a mode of dynamically creating script tags, so that loading of the components is achieved.

3.3.3. Component rendering: after the component code is loaded, a component instance is created by using a real.

3.3.4. Component update: if the remote component has an update, the component code is reloaded and a new component instance is created for updating using the react.

3.4 Locally operating DSL

DSL is a string of characters saved in a visual arrangement, a specific language, defined herein as a large string of json. Wherein the 3.4 step has multiple steps, as shown in fig. 8.

The parsing process typically includes the following steps:

3.4.1 Syntax analysis: the structure, event and data source portions of the page are parsed.

3.4.2 Page structure analysis: and recursively drawing the small-particle components on the page according to the structural data, and uploading the parameters initialized by the person.

3.4.3 Event analysis: after the page structure is analyzed, the event is bound, and the logic of the event is split into action instructions of the stripe.

3.4.4 And (3) data source analysis: the parsing of the data source is independent of structure and event and can be performed synchronously. The data source is ultimately converted into the component parameters for delivery to the interior of the component. Event-operated data source changes may also trigger changes in page structure.

Step 4, the back end interface capability is registered in an expansion point management center: the product side registers the back end interface of the original product to the expansion point management center, and automatically identifies the parameter entering and exiting structures of the interface.

Step 5, newly adding project tenants: and adding one tenant, wherein the setting content under the tenant cannot influence other tenants. The contents seen by different project tenants are self-owned and isolated by tenant rights.

Step 6, sharing product side data: and sharing the interface capacity and the extension point definition data of the product side to the designated project tenant.

Step 7, obtaining the product side interface capability: the project tenant side subscribes to the interface capability shared by the product side. Thus, the project tenant can access the interface capability of the product side.

Step 8, obtaining product side extension point definition: and the project tenant side acquires the extension point definition shared by the product side. It is known on the project which component of the front end is allowed to be customized.

Step 9, the expansion point realizes management: in the project tenant, a component expansion point list maintained at the product side can be seen, expansion points can be selected to start expansion, and an implementation mode of the expansion needs to be further set. Comprising the following steps: uploading the high code development component and the visualization orchestration component.

Wherein step 9 has a plurality of steps, as shown in fig. 3.

Step 9.1 upload high code development component: the offline developed components are edited and uploaded to an expansion point management center.

Step 9.2 visualization orchestration component: the project tenant side opens the page designer, drags the page control, composes the front-end event, and invokes the product side interface to compose a business component. When the product side is used for registering the incoming interface, the incoming and outgoing parameters of the interface can be automatically acquired to participate in the arrangement and development of the components.

As a specific embodiment: the extension point operation center is deployed. As in fig. 9.

Step 1, deploying an expansion point operation center module, as shown in fig. 4: the project side deploys the 'expansion point operation center' module, the module stores configuration data realized by expansion points in a plug-in mode, and provides a series of interface capabilities for a product side, and the method comprises the following steps: whether the expansion is realized aiming at a certain expansion point is judged, a customizing component JS file is returned, DSL characters of the customizing component are arranged, and the like.

Step 2, deriving custom configuration data: the project side exports configuration data within the tenant.

Step 3, importing custom configuration data: the project side imports configuration data to the expansion point operation center.

And 4, shutting down an expansion point operation center module: if the on-site side does not need to take effect of the customizing function, the 'extension point operation center' module is directly shut down, and the universal function of the product is automatically recovered.

As a specific embodiment: the runtime-front-end component addresses automatically. This embodiment has a number of steps, as shown in fig. 5.

Step 1, detecting whether a component has an expansion point: if the front-end component is found to have the component attribute "extension point code" in the code.

Step 2, detecting whether the component is custom-expanded: the product side front end SDK requests an expansion point operation center to inquire whether customization is realized or not through expansion point coding.

And step 3, if the custom extension implementation is not performed, automatically loading a default component at the product side. If so, the "extension Point operations center" returns the manner in which the customization was achieved (including uploading components of high code development, visualization orchestration components)

And 4, if the customization mode is a component for uploading high code development, returning the address of the component JS by an expansion point operation center, requesting the component by a page, and loading the component.

And 5, if the customization mode is a visual arrangement component and an expansion point operation center returns DSL characters of the component, dynamically analyzing DSL at the front end of the page by the SDK at the front end of the page to finish rendering of the component.

The above detailed description is merely illustrative of the preferred embodiments of the present invention and is not intended to limit the scope of the present invention. Various modifications, substitutions and improvements of the technical scheme of the present invention will be apparent to those skilled in the art from the description and drawings provided herein without departing from the spirit and scope of the invention. The scope of the invention is defined by the claims.

Claims

1. A pluggable page extension method based on a low-code front-end component, comprising:

step S6: the extension point realizes management.

2. The pluggable page extension method based on the low-code front-end component of claim 1, wherein the step S3 includes:

step S31: front-end SDK packaging parameters;

step S32: running a front end SDK;

step S33: loading a remote high-code component js;

step S34: the DSL is operated locally.

3. The pluggable page expansion method based on the low-code front-end component as claimed in claim 2, wherein the step S32 is specifically as follows:

the page calls the front-end SDK:

url represents a default component path, compxtcode is extension point code, tenant Id is tenant ID, if the compxtcode does not exist, the Url in the ajax request component parameter is used for designating resource to return and run; judging whether the extension point has custom realization or not according to the extension point code and the tenant ID request background interface if the comppextcode exists, and judging the type of the custom realization if the tenant ID does not return, and adopting a product side default realization;

if the custom realization is returned, the type of the custom realization is divided into a high code component and an arrangement component, and if the type is the high code component, a js file path is returned, and the ajax requests js file path resource operation; if the type is a orchestration component, a string of DSL is returned, and the low code running engine is invoked for rendering.

4. The pluggable page extension method based on the low-code front-end component of claim 2, wherein the step S33 includes:

5. The pluggable page extension method based on the low-code front-end component of claim 2, wherein the step S34 includes:

step S342: recursively drawing small-particle components on a page according to the structural data, and transmitting initialized parameters;

step S343: after the page structure is analyzed, binding the event, and splitting the logic of the event into action instructions of the stripe;

step S344: the analysis of the data source is independent of the structure and the event, and can be synchronously performed, and the data source is converted into the construction parameters and transmitted to the inside of the component.

6. The pluggable page extension method based on the low-code front-end component of claim 1, wherein the step S6 includes:

step S62: the visual editing component opens a page designer on the project tenant side, drags a page control, composes a front-end event, and invokes a product side interface to composes a service component; when the product side is used for registering the incoming interface, the incoming and outgoing parameters of the interface are automatically acquired to participate in the arrangement and development of the component.

7. The pluggable page extension method based on the low-code front-end component according to claim 1, further comprising version control and rollback functions, specifically comprising the following steps:

8. The pluggable page extension method based on low-code front-end component as recited in claim 1, further comprising a preview function,

step S111: adding the function of a preview component in the front-end SDK;

9. A pluggable page extension system based on a low-code front-end component, which is applicable to the pluggable page extension method based on the low-code front-end component as claimed in any one of claims 1 to 8, and is characterized by comprising: the system comprises an expansion point management center, an expansion point operation center and a front end SDK;

front-end component registration management, allowing splitting the functionality of the product into separate front-end components and registering these components to a management center;

component expansion point management, namely marking an open expansion point of a product;

the expansion point realizes management, creates a tenant space of each project, and enables the project to customize development and management components in the own tenant space;

the rear end interface is registered with the capability of registering the rear end interface of the product so as to be reused when the assembly is arranged, and the parameter entering and parameter exiting structures of the interface are automatically identified;

the front-end SDK is used for encapsulating the call of the product side page, so that the call of the front-end component is simplified.