A plug-in-based front-end page rendering method and system

Abstract

The application provides a front-end page rendering method and system based on plug-in, and relates to the technical field of data processing.The method comprises the following steps: obtaining a system event and triggering target route jump to generate initial request parameters of the target route; analyzing route configuration information to determine whether the information contains predefined plug-in processing logic; if not, a default rendering process is executed; if yes, a plug-in list containing plug-in types and priorities is determined through a plug-in dependency analysis algorithm; when there are pre-cut plug-ins, the initial request parameters are processed to generate final request parameters; a business request is initiated to a server based on the final request parameters and original response data is received; when there are post-cut plug-ins, the original response data is processed to generate final business data; and finally, the final business data is injected into a corresponding view component to execute rendering logic and complete page display.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a plugin-based front-end page rendering method and system. Background Technology

[0002] With the development of information technology, front-end development is gradually evolving towards modularity, dynamism, and low-code. Existing mainstream front-end frameworks (such as React and Vue) already support component-based development, which to some extent satisfies the need for system function reuse and expansion. However, personalized customization needs of different users still mainly rely on code branches or configuration centers. Meanwhile, micro-frontend architectures and plug-in architectures are becoming increasingly popular, but they still have limitations in terms of dynamic loading, hot updates, and remote debugging capabilities.

[0003] Currently, front-end system customization and maintenance are mainly achieved through the following methods: one is to rely on pre-compilation or server-side rendering to complete module loading; the other is to maintain independent code branches for delivery, in order to meet the customization needs of different customers.

[0004] However, when faced with the personalized needs of different customers, existing technologies usually rely on branch management, which can easily lead to code redundancy and collaboration conflicts, making it difficult to efficiently support the parallel development of multiple requirements. In addition, for unexpected problems that occur during operation, engineers often need to debug and repair on-site, which is not only time-consuming but also has high maintenance costs, lacking timeliness and flexibility. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a plug-in-based front-end page rendering method, which can solve the problems of the prior art, which usually relies on branch management to meet the personalized needs of different customers, which is prone to code redundancy and collaboration conflicts, and is difficult to efficiently support the parallel development of multiple requirements; in addition, for sudden problems that occur during operation, engineers often need to debug and repair on-site, which is not only time-consuming, but also has high maintenance costs, and lacks timeliness and flexibility.

[0006] A first aspect of this invention provides a plugin-based front-end page rendering method, comprising:

[0007] S1: Obtain system events, trigger the target route redirection based on the system events, and generate the initial request parameters for the target route;

[0008] S2: Parse the configuration information of the target route and determine whether the configuration information contains predefined plugin processing logic; if yes, proceed to S3; otherwise, execute the default rendering process and proceed to S7.

[0009] S3: Determine a list of plugins, including plugin type and plugin priority, through a plugin dependency resolution algorithm;

[0010] S4: Determine whether a pre-cutting plugin exists in the plugin list; if so, execute the plugin processing logic of the pre-cutting plugin to process the initial request parameters and generate the final request parameters; otherwise, use the initial request parameters as the final request parameters.

[0011] S5: Based on the final request parameters, initiate a core business request to the server and receive the original response data;

[0012] S6: Determine whether a back-cut plugin exists in the plugin list; if so, execute the plugin processing logic of the back-cut plugin to process the original response data and generate the final business data; otherwise, use the original response data as the final business data.

[0013] S7: Inject the final business data into the corresponding view component, execute the component rendering logic, and complete the page rendering.

[0014] A second aspect of this invention provides a plug-in-based front-end page rendering system, comprising: a processor and a memory;

[0015] The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the plug-in-based front-end page rendering method as described in the first aspect.

[0016] A third aspect of the present invention provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the plug-in-based front-end page rendering method described in the first aspect.

[0017] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0018] In this embodiment of the invention, by introducing a plug-in mechanism to replace the traditional branch management method, flexible processing of request parameters and modular expansion of business logic are achieved, thereby effectively avoiding code redundancy and collaboration conflicts, and improving the efficiency of parallel development of multiple requirements. At the same time, in the process of processing core business request and response data, the system can use plug-in logic to dynamically process data, enhance the adaptability to sudden problems during operation, reduce reliance on manual debugging and maintenance, thereby improving the flexibility and timeliness of the system and reducing maintenance costs. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0020] Figure 1 This is a flowchart illustrating a plugin-based front-end page rendering method provided in an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the structure of a plug-in-based front-end page rendering system provided in an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] The following description, in conjunction with the accompanying drawings, details the plug-in-based front-end page rendering method provided by the present invention through specific embodiments and application scenarios.

[0024] Reference manual attached Figure 1 The diagram illustrates a flowchart of a plugin-based front-end page rendering method provided by an embodiment of the present invention.

[0025] This invention provides a plugin-based front-end page rendering method, which may include the following steps:

[0026] S1: Obtain system events, trigger the target route redirection based on system events, and generate the initial request parameters for the target route.

[0027] System events are input signals that trigger routing changes or business logic execution in front-end applications, typically generated by user actions or internal system mechanisms. Examples include user interactions such as clicking navigation menus, entering query requests, and submitting forms, as well as internal events like scheduled tasks, push notifications, and permission changes. Once captured, system events serve as the starting point for the process, driving the loading of the target route and the execution of subsequent plugin processing logic.

[0028] S2: Parse the target route's configuration information and determine if the configuration information contains predefined plugin processing logic. If yes, proceed to S3. Otherwise, execute the default rendering process and proceed to S7.

[0029] Among them, plugin processing logic refers to the extended function logic that is dynamically loaded and executed based on the configuration information of the target route during the operation of the front-end application.

[0030] In one possible implementation, the default rendering process is executed in S2, and entering S7 specifically includes:

[0031] S201: Initiate a business request to the server based on the initial request parameters.

[0032] S202: Receive the raw response data returned by the server.

[0033] S203: The original response data is used as the final business data and then passed to S7.

[0034] In this embodiment of the invention, by parsing and judging the target route configuration information, when it is detected that no predefined plugin processing logic exists, the system directly executes the default rendering process. That is, it initiates a business request to the server based on the initial request parameters, receives the original response data, and uses it as the final business data for page rendering. This method ensures that the front-end application can still run normally even when the plugin is not configured or is unavailable, achieving system stability and compatibility; at the same time, it avoids additional plugin loading overhead, improves page response speed, and thus improves user experience.

[0035] S3: Determine a list of plugins, including plugin type and plugin priority, through a plugin dependency resolution algorithm.

[0036] Among them, the plugin dependency resolution algorithm refers to the process of collecting, filtering and sorting the plugins declared by the target route and its parent routes during the runtime of the front-end application.

[0037] The plugin list refers to the collection of plugins that can be actually loaded and executed in the target route after being processed by the plugin dependency resolution algorithm during the runtime of the front-end application. The plugin list includes not only the unique identifier of each plugin, but also the plugin type, priority, and merged configuration parameters.

[0038] In one possible implementation, S3 specifically includes:

[0039] S301: Read the plugin IDs declared in the target route and its parent route to form an initial plugin list.

[0040] It should be noted that by reading the plugin IDs declared by the target route and its parent routes and forming an initial plugin list, the inheritance and integrity of plugins can be guaranteed, allowing the plugin logic declared by the upper-level routes to continue to take effect in the child routes, thereby improving the reusability of the system.

[0041] S302: Remove duplicate plugin IDs from the initial plugin list.

[0042] S303: By using a merging strategy, configuration parameters of plugins that are repeatedly declared are merged to form a first candidate plugin list.

[0043] In one possible implementation, the merge strategy employs shallow merge or overwrite.

[0044] In this embodiment of the invention, the configuration parameters of duplicated plugins are merged using a merging strategy, which can ensure the consistency of plugin functionality while supporting flexible coverage of different levels of configuration, thereby improving the flexibility and maintainability of plugin configuration.

[0045] S304: Construct runtime context object information.

[0046] Optionally, the context object includes user (roles, permissions, tags), env (application version, device type, language, feature switches, etc.), route (parameters and query information), and app (application instance).

[0047] In this embodiment of the invention, a runtime context object is constructed, enabling the plugin to perceive user information, environment information, routing information, and application instances, thereby achieving context-aware dynamic loading and enhancing the system's intelligence and customization capabilities.

[0048] S305: Based on the plugin's plugin ID, asynchronously load the metadata of each plugin in the first candidate plugin list from the remote server. The metadata includes the plugin type, priority, and judgment function.

[0049] Specifically, Route Guard triggers the plugin manager's parsing process, where the manager collects all plugin IDs declared on the current route chain (from the root route to the current route).

[0050] S306: Based on the context object information, execute the conditional judgment function for each plugin in the first candidate plugin list and determine whether the return result is successful. If yes, keep the corresponding plugin. Otherwise, remove the corresponding plugin to form the second candidate plugin list.

[0051] In this embodiment of the invention, executing the condition judgment function of the plugin and filtering the plugin accordingly can ensure that only plugins that conform to the current operating environment and business scenario are retained, thereby realizing the on-demand loading of plugins and improving the efficiency and reliability of system operation.

[0052] S307: Set the execution order of each plugin in the second candidate plugin list based on plugin type and priority.

[0053] It should be noted that for items with the same priority, the relative order is determined according to stable rules (such as the order of declaration).

[0054] S308: Sort the plugins in the second candidate plugin list according to the execution order to determine the plugin list that includes plugin type and plugin priority.

[0055] Specifically, the algorithm reads the `plugins` field from the current route's `meta` configuration and recursively searches upwards through the `plugins` fields of all its parent routes, aggregating all declared plugins to form an initial plugin list. This step ensures plugin inheritance. The same plugin may be declared in multiple levels of routes. The algorithm needs to deduplicate based on the plugin ID and merge their configuration parameters. The merging strategy typically uses shallow merging or overriding. For each plugin in the list, its conditional loading strategy is executed. Plugins that do not meet the loading conditions are filtered out based on the runtime environment, generating a final list of plugins to be loaded. Priority sorting: After dependency sorting, plugins without dependencies are further sorted according to their explicitly declared `priority` attribute. Plugins with higher priority are executed first.

[0056] It should be noted that this invention designs a complete aspect-oriented programming scheme. This scheme supports three intervention methods: (1) Pre-intervention (PRE_HOOK): By proxying the original method, input parameters or variables can be modified before the method is executed. Typical applications include: forcibly modifying API request parameters, adjusting default configuration values, etc.; (2) Post-intervention (POST_HOOK): By intercepting the method return value, the output result can be processed again. Typical applications include: data format conversion, appending monitoring logs, exception handling, etc.; (3) Complete replacement (REPLACE): Allows complete rewriting of business logic or replacement of UI components, while maintaining the compatibility of the original component interfaces. These intervention methods are all implemented through dynamic code injection, without modifying the original code. Through the synergistic effect of multiple innovations, the front-end application is made dynamic, customized, and operable. Compared with traditional solutions, significant improvements have been made in development efficiency, operation and maintenance costs, and user experience.

[0057] In one possible implementation, the process after S3 includes:

[0058] S3A: Determine if a function replacement plugin exists in the plugin list. If yes, the function replacement plugin takes over the processing flow, generates the final business data, and proceeds to S7. Otherwise, proceed to S4.

[0059] In one possible implementation, the function replacement plugin in S3A takes over the processing flow and generates the final business data, specifically including:

[0060] S3A1: Invokes the feature replacement plugin, transferring full context control to the feature replacement plugin.

[0061] S3A2: The function replacement plugin is context-based and independently completes request initiation and response data processing, outputting the final business data.

[0062] Specifically, if the plugin type is a function replacement plugin, it completely takes over the default process; the function replacement plugin is invoked, and complete context control, including the initial request parameters, is transferred to it. This plugin independently completes the entire process from request retrieval initiated by its internal logic, data processing, to generating the final result. It can completely rewrite the business logic or selectively call back the default method. The output of this step is also a defined, final set of business data.

[0063] In this embodiment of the invention, by introducing a function replacement plugin, when the existence of a function replacement plugin is detected, the system transfers complete context control of the processing flow to the plugin, which independently completes request initiation, data processing, and result generation, thereby achieving a complete replacement of the default business logic. This approach not only avoids direct modification of the core code, ensuring the stability and maintainability of the system, but also allows for flexible customization of logic according to different customers or business scenarios, enabling rapid iteration and personalized expansion. Simultaneously, the function replacement plugin can be dynamically updated via remote loading, giving the system the ability to upgrade seamlessly and repair remotely, significantly reducing operational costs and improving the user experience.

[0064] S4: Determine if a pre-switching plugin exists in the plugin list. If so, execute the plugin processing logic of the pre-switching plugin to process the initial request parameters and generate the final request parameters. Otherwise, use the initial request parameters as the final request parameters.

[0065] In one possible implementation, the plugin processing logic of the pre-cutting plugin in S4 processes the initial request parameters to generate the final request parameters, specifically including:

[0066] S401: Invoke the pre-cutting plugin, and take the initial request parameters as input to execute the plugin processing logic of the pre-cutting plugin.

[0067] S402: Receive the output of the pre-cutting plugin.

[0068] S403: Parse the output of the pre-cutting plugin to determine if the initial request parameters have been modified. If so, use the parameters in the output to overwrite the initial request parameters to obtain the final request parameters. Otherwise, use the initial request parameters as the final request parameters.

[0069] In this embodiment of the invention, by introducing pre-cutting plugin logic, the system can preprocess the initial request parameters before the business request is initiated, call the pre-cutting plugin and parse its output results, and modify or enhance the request parameters according to business needs. This ensures the correctness and integrity of the request parameters and reduces the risk of request failure. On the other hand, it provides flexible parameter customization capabilities for different customers or business scenarios, realizes scalable control of the request chain, and thus improves the security, compatibility and adaptability of the system.

[0070] S5: Based on the final request parameters, initiate core business requests to the server and receive raw response data.

[0071] Raw response data refers to the response results returned directly by the server after the front-end application initiates a business request to the server based on the final request parameters, without any plugin processing. This data typically contains core information required by the business logic, such as query results, status codes, user information, or configuration parameters.

[0072] It should be noted that the final request parameters output are used to initiate an asynchronous data request to the server. This step is a crucial juncture, and the content of the request is determined by the preceding plugin chain.

[0073] In this embodiment of the invention, by using the final request parameters to initiate a core business request to the server and receiving the original response data, it can be ensured that the system initiates a request according to the customized and verified parameters after completing the pre-plugin chain processing, thereby improving the accuracy of the request and the reliability of business execution.

[0074] S6: Determine if a back-switching plugin exists in the plugin list. If so, execute the plugin processing logic of the back-switching plugin to process the original response data and generate the final business data. Otherwise, use the original response data as the final business data.

[0075] It should be noted that the final business data refers to the deterministic data result that can be directly used for page rendering, obtained after the front-end application completes the core business request, through preprocessing of request parameters by the front-end plugin, the raw response data returned by the server, and further processing by the back-end plugin or function replacement plugin. This data usually already meets the needs of business display or interaction.

[0076] In one possible implementation, the plugin processing logic of the post-cut plugin is executed in S6 to process the original response data and generate the final business data, specifically including:

[0077] S601: Invoke the back-cutting plugin and execute the plugin processing logic of the back-cutting plugin with the original response data as input.

[0078] S602: Receive the output of the cut-off plug-in.

[0079] S603: Parse the output of the post-cutting plugin to determine whether the original response data has been processed. If so, replace or merge the original response data with the data returned by the post-cutting plugin to form the final business data. Otherwise, use the original response data as the final business data.

[0080] Optionally, the raw response data may be processed, which may include filtering sensitive fields, adding status codes, or performing data standardization transformations.

[0081] In this embodiment of the invention, calling the post-cutting plugin and parsing its output allows for filtering, transformation, or enhancement of the response data. For example, sensitive fields can be removed, status indicators added, or data structures standardized, thereby ensuring the security, integrity, and consistency of business data. This approach not only improves the system's adaptability to different business scenarios but also enables the final business data to be output in a form that better meets the needs of front-end rendering and interaction, reducing the additional processing overhead of front-end components and thus improving overall operating efficiency and user experience.

[0082] S7: Inject the final business data into the corresponding view component, execute the component rendering logic, and complete the page rendering.

[0083] It's important to note that view components are independent UI modules in a front-end application used to receive final business data and execute rendering logic. They are typically composed of component units provided by frameworks (such as React and Vue), capable of transforming input data into visual user interface elements. View components not only display the processed business results but also implement interactive functions based on business logic, such as table display, form submission, chart drawing, or status indicators.

[0084] In this embodiment of the invention, the view component, as the carrier of the final business data, ensures that the results of the data processing chain can be presented to the user in an intuitive, dynamic, and scalable manner.

[0085] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0086] In this embodiment of the invention, by introducing a plug-in mechanism to replace the traditional branch management method, flexible processing of request parameters and modular expansion of business logic are achieved, thereby effectively avoiding code redundancy and collaboration conflicts, and improving the efficiency of parallel development of multiple requirements. At the same time, in the process of processing core business request and response data, the system can use plug-in logic to dynamically process data, enhance the adaptability to sudden problems during operation, reduce reliance on manual debugging and maintenance, thereby improving the flexibility and timeliness of the system and reducing maintenance costs.

[0087] Reference manual attached Figure 2 The diagram illustrates the structure of a plug-in-based front-end page rendering system provided by an embodiment of the present invention.

[0088] This invention provides a plug-in-based front-end page rendering system 20, including: a processor 201 and a memory 202;

[0089] The memory 202 stores programs or instructions that can run on the processor 201. When the program or instructions are executed by the processor 201, they implement the steps of the above-described plug-in-based front-end page rendering method and achieve the same technical effect. To avoid repetition, the present invention will not elaborate further.

[0090] It should be understood that the processor 201 in this embodiment of the invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0091] It should also be understood that the memory 202 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0092] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0093] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0094] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0096] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0097] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0099] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] This invention provides a readable storage medium comprising: storing a program or instructions on the readable storage medium, wherein when the program or instructions are executed by a processor, the program or instructions implement the steps of the above-described plug-in-based front-end page rendering method and achieve the same technical effect. To avoid repetition, this invention will not elaborate further.

[0101] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A plug-in based front-end page rendering method, characterized in that, The method comprises the following steps: S1: acquiring a system event, triggering a jump of a target route based on the system event, and generating initial request parameters of the target route; S2: analyzing configuration information of the target route, and determining whether the configuration information contains predefined plug-in processing logic; if yes, S3 is entered; otherwise, a default rendering process is executed, and S7 is entered; S3: determining a plug-in list containing plug-in types and plug-in priorities by using a plug-in dependency analysis algorithm; S4: determining whether there is a pre-cut plug-in in the plug-in list; if yes, the initial request parameters are processed by using plug-in processing logic of the pre-cut plug-in to generate final request parameters; otherwise, the initial request parameters are taken as the final request parameters; S5: based on the final request parameters, a core business request is initiated to a server, and original response data is received; S6: determining whether there is a post-cut plug-in in the plug-in list; if yes, the original response data are processed by using plug-in processing logic of the post-cut plug-in to generate final business data; otherwise, the original response data are taken as the final business data; S7: the final business data are injected into a corresponding view component, a component rendering logic is executed, and page rendering is completed; The S3 specifically comprises the following steps: S301: reading plug-in IDs declared by the target route and a parent route of the target route to form an initial plug-in list; S302: performing a de-duplication process on repeated plug-in IDs in the initial plug-in list; S303: performing a merging process on configuration parameters of a same plug-in declared repeatedly to form a first candidate plug-in list; S304: constructing context object information of a runtime; S305: based on the plug-in IDs, metadata of each plug-in in the first candidate plug-in list are loaded from a remote server asynchronously, wherein the metadata comprises a plug-in type, a priority, and a judgment function; S306: based on the context object information, a condition judgment function of each plug-in in the first candidate plug-in list is executed, and it is determined whether a returned result is successful; if yes, the corresponding plug-in is retained; otherwise, the corresponding plug-in is removed to form a second candidate plug-in list; S307: based on the plug-in type and the priority, an execution order of each plug-in in the second candidate plug-in list is set; S308: based on the execution order, each plug-in in the second candidate plug-in list is sorted to determine a plug-in list containing plug-in types and plug-in priorities. The S2 comprises the following steps: S201: based on the initial request parameters, a business request is initiated to the server; S202: original response data returned by the server are received; S203: the original response data are taken as the final business data, and S7 is entered.

2. The plug-in based front-end page rendering method according to claim 1, wherein, The merging strategy adopts a shallow merging or an overlay. The method further comprises the following steps after the S3: S3A: determining whether there is a function replacement plug-in in the plug-in list; if yes, the function replacement plug-in takes over the processing flow to generate the final business data, and S7 is entered; otherwise, S4 is entered. ​ 3. The plug-in based front-end page rendering method according to claim 1, wherein, ​ 4. The plug-in based front-end page rendering method according to claim 1, wherein, ​ ​ 5. The plug-in based front-end page rendering method according to claim 4, wherein, The function replacement plug-in in the S3A takes over the processing flow, and generating the final service data specifically includes: S3A1: calling the function replacement plug-in, and handing over the complete context control right to the function replacement plug-in; S3A2: the function replacement plug-in independently completes the request initiation and response data processing based on the context information, and outputs the final service data.

6. The plug-in based front-end page rendering method according to claim 1, wherein, The plug-in processing logic of the front plug-in in the S4 processes the initial request parameter, and generating the final request parameter specifically includes: S401: calling the front plug-in, and taking the initial request parameter as input, and executing the plug-in processing logic of the front plug-in; S402: receiving the output result of the front plug-in; S403: analyzing the output result of the front plug-in, and judging whether the initial request parameter is modified; if yes, the parameter in the output result is used to replace the initial request parameter to obtain the final request parameter; otherwise, the initial request parameter is taken as the final request parameter.

7. The plug-in based front-end page rendering method according to claim 1, wherein, The plug-in processing logic of the back plug-in in the S6 processes the original response data, and generating the final service data specifically includes: S601: calling the back plug-in, and taking the original response data as input to execute the plug-in processing logic of the back plug-in; S602: receiving the output result of the back plug-in; S603: analyzing the output result of the back plug-in, and judging whether the original response data is processed; if yes, the data returned by the back plug-in is used to replace or merge the original response data to form the final service data; otherwise, the original response data is taken as the final service data.

8. A plug-in based front-end page rendering system, characterized in that, including: a processor and a memory; The memory stores programs or instructions that can be run on the processor, and the programs or instructions are executed by the processor to realize the steps of the plug-in-based front-end page rendering method according to any one of claims 1 to 7.

9. A readable storage medium, characterized by, The readable storage medium stores programs or instructions, and the programs or instructions are executed by the processor to realize the steps of the plug-in-based front-end page rendering method according to any one of claims 1 to 7.

Images