Method and apparatus for managing component resources
By automating the parsing and fragmentation of front-end plugin packages, a global component index and configuration description file are generated, solving the problems of flexibility, scalability, and performance in front-end development systems. This enables dynamic registration and on-demand rendering of components, improving development efficiency and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING JOIN CHEER SOFTWARE
- Filing Date
- 2026-01-16
- Publication Date
- 2026-05-22
Smart Images
Figure CN121541874B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and specifically to a method and apparatus for managing component resources. Background Technology
[0002] Modern business management systems and enterprise-level web applications face increasingly complex and ever-changing business scenarios. As the core carrier of user interaction, the front-end needs to provide highly customized interactive interfaces such as forms, dashboards, and approval workflows based on the individual needs of different departments, processes, and users. Traditional implementation methods typically adopt a "one requirement, one development" model, meaning that a separate set of front-end components or even complete pages are written for each different business scenario.
[0003] While this model can meet functional requirements in the short term, it brings many thorny problems from the perspective of system architecture and long-term evolution: First, the system lacks flexibility. Any minor adjustment to business logic or interface modification requires developers to be deeply involved, modifying the source code and redeploying, making it impossible to quickly respond to business changes. Second, it lacks scalability. The system's functional boundaries are rigid, making it difficult to support third parties or business personnel to independently extend new functions. Each new requirement means an "intrusive" modification to the main system. Finally, there is a lot of repetitive work. Similar form controls and interaction logic are repeatedly implemented on different pages, which not only leads to low development efficiency but also causes a sharp increase in code maintenance costs, creating a "reinventing the wheel" dilemma. Summary of the Invention
[0004] In view of the problems in the prior art, the embodiments of this application provide a method and apparatus for managing component resources, which can at least partially solve the problems existing in the prior art.
[0005] This application proposes a method for managing component resources, the method comprising:
[0006] Scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package contains a component logic file defined using a first registration method and a component configuration description file defined using a second registration method;
[0007] Based on the parsing results, the logic code of the component is split into fragments, and a global component index file is generated that records the mapping relationship between the component and the fragment file.
[0008] The component configuration description files of all plugins are merged to generate a unified global component configuration description file. The global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime.
[0009] In some embodiments, identifying and parsing plugin packages conforming to a preset format includes:
[0010] Identify the business scenario types of the components declared in the plugin package;
[0011] Parse the component logic file to obtain the registered component implementation code and the business group information to which the component belongs;
[0012] The component configuration description file is parsed to obtain a set of configurable parameters for the component defined by structured data, wherein the component identifier defined in the component configuration description file is associated with the component identifier registered in the component logic file.
[0013] In some embodiments, the step of segmenting the component's logic code based on the parsing results and generating a global component index file that records the mapping relationship between the component and the segmented files includes:
[0014] Based on the component business scenario type and / or the business grouping information, the parsed component implementation code is divided to generate multiple component logic shard files;
[0015] Create a global component index file, which records the correspondence between each component identifier and the component logical segment file in which it resides.
[0016] In some embodiments, the method further includes:
[0017] A visual configuration interface is provided, and based on the global component configuration description file, the interface displays the optional components and their configurable parameters.
[0018] In response to the user's component selection and parameter configuration operations on the interface, a form structure description file is generated and stored. The form structure description file is used to describe the component composition of the business form configured by the user and the parameter values of each component.
[0019] In some embodiments, the form structure description file is a JSON format file, the contents of which include the component layout structure of the business form, the type identifiers of the included components, and the specific parameter values assigned to the configuration items of each component.
[0020] In some embodiments, the method further includes:
[0021] In response to an access request for a target form, obtain the form structure description file corresponding to the target form;
[0022] Parse the form structure description file to determine one or more target components and their corresponding instantiation configuration parameters required to render the target form;
[0023] Based on the global component index file, determine the component logic fragment file associated with the target component, and dynamically load the determined component logic fragment file;
[0024] Based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, the target component is dynamically instantiated and rendered to combine and present the target form.
[0025] In some embodiments, the dynamic loading and dynamic instantiation include:
[0026] A global component manager is established during application initialization;
[0027] Determine the group of components to be loaded based on the context of the current access request;
[0028] Based on the global component index file, asynchronously request and load the component logic shard file corresponding to the component group, and register the components defined in the shard file to the global component manager;
[0029] After parsing the form structure description file, the definition of the target component is queried and obtained through the global component manager;
[0030] By leveraging the dynamic component capabilities of the front-end framework, and combining the obtained component definition with the instantiation configuration parameters, a component instance is created and rendered.
[0031] In another aspect, this application proposes a component resource management device, the device comprising:
[0032] The first parsing module is used to scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package includes a component logic file defined using a first registration method and a component configuration description file defined using a second registration method;
[0033] The first generation module is used to perform sharding of the component's logic code based on the parsing results, and generate a global component index file that records the mapping relationship between the component and the shard file;
[0034] The second generation module is used to merge the component configuration description files of all plugins to generate a unified global component configuration description file. The global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime.
[0035] In some embodiments, the apparatus further includes:
[0036] The display module provides a visual configuration interface and displays selectable components and their configurable parameters in the interface based on the global component configuration description file.
[0037] The third generation module is used to generate and store a form structure description file in response to the user's component selection and parameter configuration operations on the interface. The form structure description file is used to describe the component composition of the business form configured by the user and the parameter values of each component.
[0038] In some embodiments, the apparatus further includes:
[0039] The acquisition module is used to acquire the form structure description file corresponding to the target form in response to an access request for the target form;
[0040] The second parsing module is used to parse the form structure description file and determine one or more target components and their corresponding instantiation configuration parameters required to render the target form;
[0041] The loading module is used to determine the component logic fragment file associated with the target component based on the global component index file, and dynamically load the determined component logic fragment file;
[0042] The instantiation and rendering module is used to dynamically instantiate and render the target component based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, so as to combine and present the target form.
[0043] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in any of the above embodiments.
[0044] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the above embodiments.
[0045] The method and apparatus provided in this application embodiment realize the dynamic registration, collection, management and rendering of front-end components through a plug-in architecture, which supports business personnel to configure and extend form functions as needed at runtime without modifying the main system code or redeploying. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:
[0047] Figure 1 This is a flowchart illustrating a method for constructing a component resource library for dynamic rendering, provided in one embodiment of this application.
[0048] Figure 2 This is a partial flowchart illustrating a method for constructing a component resource library for dynamic rendering, provided in one embodiment of this application.
[0049] Figure 3 This is a partial flowchart illustrating a method for constructing a component resource library for dynamic rendering, provided in one embodiment of this application.
[0050] Figure 4 This is a flowchart illustrating a configuration method for dynamically rendering forms provided in an embodiment of this application.
[0051] Figure 5 This is a flowchart illustrating a dynamic rendering method for a form provided in an embodiment of this application.
[0052] Figure 6 This is a partial flowchart illustrating a dynamic rendering method for a form provided in one embodiment of this application.
[0053] Figure 7 This is a schematic diagram of the workflow of a component collector provided in one embodiment of this application.
[0054] Figure 8 This is a schematic diagram of the workflow of a dynamic rendering engine provided in one embodiment of this application.
[0055] Figure 9 This is a complete usage process from requirements to system rendering of the "plugin-oriented form collection and rendering system" provided in one embodiment of this application.
[0056] Figure 10 This is a schematic diagram of a component resource library construction device for dynamic rendering provided in an embodiment of this application.
[0057] Figure 11 This is a schematic diagram of the structure of a configuration device for dynamically rendering forms provided in an embodiment of this application.
[0058] Figure 12 This is a schematic diagram of the structure of a dynamic rendering device for a form provided in an embodiment of this application.
[0059] Figure 13 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily arranged.
[0061] The terms “first,” “second,” etc., used in this document are not intended to specifically refer to order or sequence, nor are they used to limit this application; they are merely used to distinguish elements or operations described using the same technical terms.
[0062] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.
[0063] The use of “and / or” in this document includes any or all of the items mentioned.
[0064] To better understand this application, the research background of this application will be introduced below:
[0065] Currently, component-based development is widely used in front-end development, which encapsulates UI elements, styles, and interaction logic into reusable components (such as Vue components and React components). This model improves development efficiency and code maintainability to a certain extent by modularizing the code.
[0066] However, existing component-based solutions are essentially still a form of "static encapsulation." The typical workflow is as follows: developers pre-integrate the required components into the business code before compilation, and then a bundling tool (such as Webpack or Vite) compiles, bundles, and generates the final static resource files along with the component code. This model has the following inherent drawbacks:
[0067] Poor flexibility and rigid functionality: The system's functionality is completely fixed during compilation and packaging. To add, modify, or remove a feature, the source code must be modified and the entire build and deployment process must be repeated, making it impossible to achieve "online" dynamic expansion and updates.
[0068] Poor scalability: Expanding with new features heavily relies on developers modifying and releasing the main system code, making it difficult to build an ecosystem that allows third-party developers to freely extend functionality through plugins. The upper limit of system functionality is locked in the early design stages.
[0069] Resource redundancy and performance degradation: To avoid potentially needed features later, developers often bundle a large number of potentially required components in advance, resulting in a large final JavaScript package. The user's browser needs to load the entire package, but may only use a small portion of the functionality, wasting network bandwidth and browser parsing time, and impacting first-screen loading performance.
[0070] Currently, there are some solutions in the industry that attempt to solve the above-mentioned technical problems, such as using asynchronous loading (CodeSplitting) or micro-fronttends architecture.
[0071] However, asynchronous loading usually requires pre-defining split points in the source code, and it is still within the scope of "static"; while micro front-end architecture is more about solving the problems of team collaboration and large application decomposition. Its sub-application granularity is relatively coarse, and it lacks a unified and efficient management mechanism for the dynamic aggregation and rendering of fine-grained UI components, and its implementation is complex.
[0072] Therefore, existing technologies lack a unified framework that can dynamically discover, collect, load, and render fine-grained front-end components at runtime, making it impossible to achieve true "plug-and-play" front-end extensions.
[0073] Based on this, this application provides a component resource management method, specifically including a method for constructing a component resource library for dynamic rendering, a method for configuring dynamically renderable forms, and a method for dynamically rendering forms. This aims to address the systemic deficiencies in flexibility, scalability, reusability, and performance commonly found in the front-end development of existing business management systems. Specifically, it includes:
[0074] The system's functionality is rigid and unable to dynamically respond to business changes: Traditional system functions are fixed during compilation and packaging. Any addition or modification of functions (such as form fields, business processes, and UI components) requires modifying the source code, rebuilding, and redeploying the entire system, making "hot-swappable" function updates impossible. This creates a contradiction between frequent changes in business requirements and long system release cycles and high costs.
[0075] Poor scalability and limited system evolution capabilities: The system's functional boundaries are closed, making it difficult to support independent development and integration of new features by third parties or across teams. Extending functions requires deep coupling with the main system code, posing risks of strong technology stack dependencies and version conflicts. Building a system ecosystem is difficult, making it impossible to construct an open functional extension platform.
[0076] Low component reuse rate and high development and maintenance costs: Similar functional components are repeatedly developed in different business scenarios, resulting in serious code redundancy. The lack of standardized interfaces and unified management mechanisms between components leads to "reinventing the wheel" and maintenance difficulties. Development efficiency is low, the code library is bloated, and long-term maintenance costs increase exponentially.
[0077] Poor resource loading performance negatively impacts user experience: To meet potential functional requirements, the initial system package often contains a large amount of code for unused components, resulting in excessively long initial screen loading times and wasted network resources. This presents a challenge in balancing application performance with feature richness.
[0078] The following Table 1 explains the technical terms used in this application.
[0079] Table 1: Technical Terminology
[0080]
[0081] Figure 1 This is a flowchart illustrating a method for constructing a component resource library for dynamic rendering, as provided in an embodiment of this application. Figure 1 As shown in the embodiment of this application, a method for constructing a component resource library for dynamic rendering includes:
[0082] S11. Scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package includes a component logic file defined using a first registration method and a component configuration description file defined using a second registration method;
[0083] In step S11, scanning refers to the process by which system build tools (such as extend-script scripts) actively and automatically traverse and inspect a specified directory or repository.
[0084] Predefined plugin sources: These refer to plugin storage locations that are pre-configured in project configuration files (such as solution files). They can point to one or more npm repository directories or a specific set of file paths. Their "predefined" nature ensures the determinism and configurability of the collection process, avoiding blind, unstructured searches.
[0085] Identification: During the scanning process, this refers to determining whether a software package is a "plugin" required by the system, based on preset format specifications. The criteria for judgment include: whether a specific configuration file exists in the package structure, and whether a specific plugin type (such as gms-plugin) is declared.
[0086] Analysis: This refers to reading and structurally analyzing the content of the identified plugin package. This involves more than just reading the file; it involves understanding its internal structure and semantics.
[0087] Preset format: refers to the structural specifications for plugin packages defined by this invention. A plugin package that conforms to the format shall contain at least: a declaration file (such as a specific field in package.json) to indicate its plugin type; a component logic file defined using the "first registration method" (such as app.js); and a component configuration description file defined using the "second registration method" (such as emcon.js).
[0088] The first registration method is mcon registration, which is a specification for registering component business logic and interactive behavior through JavaScript or other code.
[0089] Component logic file: This can be a JavaScript file (e.g., app.js). This file contains all the runtime code required for the component, including its UI template, styles, data logic, methods, lifecycle hooks, etc. By calling framework-specific APIs or following specific syntax, the component is registered under a group, making it discoverable by the system. Dynamic imports are supported (e.g., `()=> import('xxx')`), which is the technical foundation for runtime on-demand loading.
[0090] The second registration method is emcon registration, which is a specification for defining configurable parameters of components through structured data (such as JSON).
[0091] Component configuration description file: This can be a JSON file (e.g., emcon.js). This file does not contain any runtime logic, but declaratively describes the component's configurable items (such as tags, default values, validation rules, option lists, etc.), including their types, default values, and whether they are required. It provides a unified, machine-readable "configuration manual" for the component, enabling subsequent "secondary development platforms" to generate a visual configuration interface without understanding the component's internal code. The component identifier (name) defined in the file must strictly match the identifier registered in the mcon file; this is the key link between the "configuration description" and the "logic implementation." It supports setting priorities for configuration items, providing a solution for merging and overriding configurations from different sources.
[0092] Through an automated "scan-identify-parse" process, the system achieves automated and centralized collection of component resources, laying the foundation for an ecosystem and completely changing the traditional method of manually importing components. The system can automatically discover new components from predefined sources (such as public or private npm repositories) without requiring modifications to the main system's build configuration. This overcomes the pain points of poor scalability and repetitive development. Third-party developers only need to follow the specifications to publish plugin packages, which will then be automatically integrated by the system, thus building an open front-end component ecosystem.
[0093] By parsing the dual registration files, the separation of "logic" and "configuration" is achieved, providing support for dynamic processing: parsing the mcon file yields the component's "executable capabilities"; parsing the emcon file yields the component's "configurable properties." This separation is a key architectural design. It provides a purely data-driven foundation for visual configuration (secondary development platform): the platform only needs to read the emcon to generate the configuration UI, without needing to touch the code at all. It provides a basis for runtime dynamic rendering: the rendering engine loads code capabilities through the mcon and performs personalized rendering through the instantiation parameters of the emcon (from the form description file). This collectively solves the problems of "rigid system functionality" and "poor flexibility." It creates the necessary conditions for subsequent build-time optimization: the parsing results (code and configuration description) of this step are the "raw materials" for all subsequent optimization operations (such as sharding, index building, and configuration merging).
[0094] In summary, step S11 is the "data ingestion" stage of the entire invention process. It automatically transforms scattered and heterogeneous plug-in packages into "component logic" and "configuration description" data that can be uniformly processed within the system and have a clear structure, providing standardized and high-quality input for subsequent "resource library construction," "visual configuration," and "dynamic rendering."
[0095] S12. Based on the parsing results, the logic code of the component is segmented, and a global component index file is generated that records the mapping relationship between the component and the segmented file.
[0096] In step S12, the parsing result refers to the structured data obtained from the "identify and parse" operation in step S11. Specifically, it includes: the executable component implementation code extracted from the mcon (first registration method) file of each plugin package; and the meta-information associated with this code, such as component identifier, business scenario (e.g., gms-plugin), and business grouping information (e.g., "form control", "chart").
[0097] The component's logic code: This refers to the front-end code, such as JavaScript, extracted from the mcon file to implement specific functions.
[0098] Sharding: This refers to splitting and recombining the collected logic code of all components into multiple independent physical files according to a certain strategy, rather than packaging it into a single large file. Sharding can be based on component business scenario type and / or business grouping information. For example, all the code of "form control" type components can be divided into one shard, and "chart display" type components into another shard. Specifically, an "even distribution strategy" can be used to generate multiple (e.g., 6) numbered files (e.g., app.0.js, app.1.js, ..., app.5.js). The difference from general "code splitting": Sharding here is an automated, strategy-based global optimization based on component meta-information during the build process, unlike asynchronous loading where split points are manually set in the business source code.
[0099] Global Component Index File: The core of this file is establishing a "mapping relationship," i.e., a key-value pair database. Where: Key: Component identifier (i.e., the component's unique name, consistent with the identifiers in mcon and emcon). Value: The identifier of the component's logic shard file (such as file number 0, 1, etc., or filename). This index file is crucial for runtime "finding the right component." When a specific component needs to be loaded, the dynamic rendering engine can immediately determine which shard file to load by querying this index, thus achieving efficient component location.
[0100] By implementing two major operations, "sharding" and "index generation," the system's performance, maintainability, and scalability have been significantly improved, solving key bottlenecks in existing technologies.
[0101] This represents a fundamental shift from "static, large packages" to "dynamic, sharded loading," optimizing loading performance. The traditionally single, massive `vendor.js` or `app.js` file is split into multiple smaller, business-oriented shard files, overcoming the pain points of "resource redundancy and performance degradation." At runtime, the user's browser does not need to load all component code; instead, it only loads one or a few relevant shard files based on the current page context (e.g., loading only the shards needed for form pages). This significantly reduces network traffic and browser parsing / compilation time, greatly improving first-screen loading speed and page responsiveness, and enhancing the user experience.
[0102] A highly efficient runtime component discovery mechanism was created to support true dynamic rendering: the generated "global component index file" provides the runtime with a lightweight, millisecond-responsive component lookup table. Without this index, dynamically finding a component at runtime would likely require traversing or attempting to load all fragments, resulting in extremely low efficiency. The existence of the index allows the "dynamic rendering engine" to instantly locate the resource position of a component by its name, much like looking up a dictionary, achieving precise and fast on-demand loading. This is the technical prerequisite for implementing the dynamic rendering mechanism of "querying, loading, and instantiating plugin components on demand based on configuration parameters and context."
[0103] It achieves manageability and optimization potential for build resources: sharding strategies (such as grouping by business scenario) make resource organization logic clear, and the index file, as a centralized list, uniformly manages the location information of all available components, improving system maintainability. Developers and build tools can perform more advanced optimizations based on this structure (e.g., adjusting sharding strategies according to component usage frequency, or compressing the index). At the same time, it also provides the infrastructure for subsequent possible incremental updates or shard preloading and other advanced features.
[0104] This supports the system's scalability: the process is fully automated. Once a new plugin is scanned and parsed, its component code is automatically incorporated into the sharding strategy and updated in the global index. This means that extending functionality (adding components) does not disrupt the existing sharding and indexing structure, allowing the system to seamlessly integrate new components. This strengthens the ecosystem's ability to "support third-party developers in freely extending functionality via plugins," resolving the issues of "weak scalability" and "rigid functional boundaries."
[0105] In summary, step S12 is an intelligent processing layer connecting "raw component collection" and "efficient runtime rendering." It resolves the conflict between package size and performance through "fragmentation processing" and addresses the efficiency issue of dynamic lookup through "generating a global index." Together, these two processes transform a collection of raw component code into a performance-optimized, well-organized, and easily accessible "component resource library," providing the core technological guarantee for achieving high-performance dynamic rendering.
[0106] S13. Merge the component configuration description files of all plugins to generate a unified global component configuration description file, wherein the global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime.
[0107] In step S13, the component configuration description files of all plugins are merged: this refers to the aggregation operation of the configuration description files from all plugin packages identified and parsed during the scanning phase. This is a batch processing and data fusion process, rather than processing individual plugins. The aim is to create a global component configuration description file that covers the configuration information of all known components in the current system.
[0108] Global component configuration description file → Supports "dynamic configuration": This file provides the data foundation for the "secondary development platform". After the platform loads this file, it can parse out all the configurable items, their types, and constraints of all components without knowing the internal code, thereby automatically generating a visual configuration interface for business personnel to design forms.
[0109] Global component index file → Supports "on-demand rendering": This file provides an addressing map for the "dynamic rendering engine". After the engine determines which components are needed based on the form configuration (JSON), it can immediately know which code segment file should be loaded by querying this index file, thus achieving accurate and efficient code loading.
[0110] Step S13, by "merging and generating a global configuration description file", achieves the transformation from raw, scattered configuration data to standardized, operable information, generating key system-level value.
[0111] It achieves centralized and standardized management of configuration information, laying the foundation for visual configuration: configuration descriptions that were previously scattered across various plugins and may have inconsistent formats are unified, aggregated, and standardized into a single system-level standard file, completely resolving the maintenance difficulties caused by the lack of standardized interfaces and unified management mechanisms between components. This allows business personnel, without technical background, to configure complex forms on a centralized platform (secondary development platform) based on this unified "menu," through point-and-click and form-filling. This achieves complete decoupling of business logic from front-end code, directly addressing the core pain point of "rigid system functionality that cannot dynamically respond to business changes."
[0112] It ensures configuration consistency and scalability: Merge conflicts are handled through preset "priority rules," guaranteeing the determinism and rationality of the final configuration definition. When a new plugin is added, its configuration description is automatically merged into this global file during the next build. This allows the configuration capabilities of new components to be automatically and seamlessly integrated into the configuration platform, supporting the system's ecological evolution. Simultaneously, the priority mechanism allows for personalized overriding and extension of basic components, meeting the customization needs of complex business scenarios.
[0113] Together with the index file, these form the two pillars of "data-driven" dynamic rendering: the global component configuration description file answers the question "What can be configured?"; the global component index file answers the question "Where is the code?". Together, they support the complete data flow from "business configuration" to "interface rendering."
[0114] In summary, step S13 is the "information hub" generation step in the construction phase. The global component configuration description file it produces complements the global component index file produced in the previous step, together forming the "dual-engine metadata" of the entire plug-in form system. One drives the front-end's visual, low-code configuration experience, while the other drives the back-end's precise and efficient code loading and rendering execution. Together, they transform the "dynamic expansion" and "plug-and-play" capabilities of this invention from a concept into a reliable and efficient technical reality.
[0115] The component resource library construction method for dynamic rendering provided in this application transforms discrete, static plug-in components from the development phase into a standardized, optimizable, and runtime-driven central resource library through automated scanning and parsing, intelligent sharding and indexing, and unified configuration aggregation. The resulting global index file and configuration description file respectively support precise and efficient on-demand code loading at runtime and visual, low-code dynamic form configuration on the business side. This construction process is the prerequisite and technological foundation for realizing all subsequent dynamic capabilities (ready-to-use, hot updates, performance optimization).
[0116] like Figure 2 As shown, in some embodiments, identifying and parsing plugin packages conforming to a preset format includes:
[0117] S111. Identify the component business scenario types declared in the plugin package;
[0118] In step S111, the component business scenario type refers to the category that the plugin actively declares in its metadata (such as a specific field in package.json) to identify its intended use case. This type can be the plugin's top-level category label. It can include:
[0119] gms-entry-plugin: Applied to rendering the main entry interface.
[0120] gms-plugin: Applied to general user interface rendering.
[0121] gms-gbc-plugin: Specifically designed for rendering the interface of a secondary development platform.
[0122] Identification: refers to the process by which the system reads and confirms this statement.
[0123] S112. Parse the component logic file to obtain the registered component implementation code and the business group information to which the component belongs;
[0124] In step S112, the component logic file is the file defined using the first registration method (mcon) (such as app.js), which contains the runtime logic of the component.
[0125] Component implementation code: The specific functional code extracted from the component logic file that can be executed by the JavaScript engine (such as Vue / React component definitions, methods, and lifecycle functions).
[0126] Business grouping information: When developers register with mcon, they assign secondary category tags (such as "basic fields", "advanced controls", "charts", "approval operations", etc.) to components based on business logic. It is more granular than "business scenario type" and is used to logically aggregate components within the same scenario.
[0127] S113. Parse the component configuration description file to obtain a set of configurable parameters for the component defined by structured data, wherein the component identifier defined in the component configuration description file is associated with the component identifier registered in the component logic file.
[0128] In step S113, the component configuration description file is the file defined using the second registration method (emcon) (such as emcon.js).
[0129] A set of configurable parameters for a component defined by structured data: This refers to the patterned data parsed from the component's configuration description file that describes all configurable attributes of the component. For example, the configuration set for an "address selector" component might include: {"label": {"type": "string", "default": "Please select an address"}, "required":{"type": "boolean", "default": false}, …}.
[0130] Component identifier association: The component name (identifier) defined in the component configuration description file (emcon) must strictly correspond to the component name (identifier) registered in the component logic file (mcon). This establishes a reliable connection between the configuration description (emcon) and the functionality implementation (mcon), ensuring that the component is found through the configuration.
[0131] Steps S111 to S113, through three-layer parsing (type -> code and grouping -> configuration), achieve deep structured extraction of plugin information, resulting in the following key effects:
[0132] The system achieves refined classification and hierarchical management of resources: by extracting "business scenario type" (S111) and "business grouping information" (S112), it gains the ability to classify component resources in a multi-dimensional and comprehensive manner. This allows subsequent optimizations (such as the sharding process in S12) to be based on more intelligent strategies. For example, coarse-grained sharding can be performed according to "business scenario type" to ensure code isolation of different types; at runtime, components of a specific "business group" can be precisely loaded according to the current page context, achieving extremely accurate resource loading, effectively reducing redundancy, and improving performance.
[0133] A reliable mapping between "configuration" and "implementation" is established, bridging visual configuration and dynamic rendering: "Component implementation code" is obtained via S112, and its corresponding "set of configurable parameters" is obtained via S113, with the "component identifier association" between the two strictly enforced. The system constructs a complete component capability model. This provides reliable data for the "secondary development platform": the platform knows what each component can do (associated with code through its identifier) and what it can be configured with (through its parameter set). Configuration operations by business personnel (based on the parameter set) can be unambiguously transmitted to the runtime and accurately trigger the rendering of the corresponding component (by finding the code through its identifier). This is the core data link guarantee for achieving "configuration-driven development" and "dynamic rendering."
[0134] It provides a structured data foundation for build-time optimization and runtime decision-making: the parsed "type", "grouping", "identifier", and "parameter set" are all highly structured metadata. They are not only used to generate indexes and configuration description files (S12, S13), but also for dependency analysis and tree-shaking optimization during build, as well as runtime access control and on-demand loading decisions, which greatly improves the overall intelligence and maintainability of the system.
[0135] In summary, the three sub-steps S111-S113 together complete a deep scan of the plugin package. It not only reads the file content but also understands the semantics and relationships within that content, transforming the original code and configuration text into a structured knowledge graph rich in semantic information that can be perfectly understood and processed by machines. This knowledge graph is the underlying data core driving the entire system to achieve intelligent resource management, precise on-demand loading, and visualized configuration.
[0136] like Figure 3As shown, in some embodiments, the step of segmenting the component's logic code based on the parsing results and generating a global component index file that records the mapping relationship between the component and the segmented files includes:
[0137] S121. Based on the component business scenario type and / or the business grouping information, divide the parsed component implementation code to generate multiple component logic shard files;
[0138] In step S121, partitioning / sharding refers to strategically cutting and recombining the implementation code of all aggregated components into several independent physical files (shards) according to specific dimensions. Its core is to break the boundaries of the traditional single bundle file. The partitioning criteria (strategy) include component business scenario types and / or business grouping information.
[0139] Component business scenario types: such as gms-entry-plugin (entry point), gms-plugin (normal UI), gms-gbc-plugin (secondary development platform). This fragmentation ensures physical isolation of code for different core scenarios.
[0140] Business grouping information: such as "form controls", "data display", "process buttons", etc. This grouping allows components with the same business function to be grouped together, improving loading relevance.
[0141] "And / or": This indicates that the strategy can be flexibly combined. For example, it can be roughly divided by "scenario type" and then further subdivided by "business group" within a certain scenario.
[0142] Component logic shard files: Independent JavaScript files generated after the sharding (e.g., app.0.js, app.1.js). Each file contains executable code for a group of components with similar business attributes.
[0143] S122. Create a global component index file, which records the correspondence between each component identifier and the component logical segment file in which it is located.
[0144] In step S122, the global component index file is a key metadata file automatically generated by the system. In essence, it is an "addressable directory" or "mapping table".
[0145] Mapping relationship: refers to the mapping information stored in the index file in the form of key-value pairs. For example, key: component identifier, that is, the unique name of the component (consistent with the identifier in mcon, emcon); value: the identifier of the component logic shard file where the component code is located (such as the shard file number, path or hash value).
[0146] The global component index file establishes a direct and precise lookup relationship from logical component names to physical code file locations.
[0147] S121 and S122 are tightly coupled and together realize the qualitative change from "static whole" to "dynamically divisible", bringing significant system-level benefits.
[0148] Revolutionary loading performance optimization has been achieved, eradicating the chronic problem of "resource redundancy": Through S121's business semantic-based sharding, the traditionally large and bloated single application package is broken down into multiple fine-grained, semantically clear shard packages. This means that the system does not need to load all the code at runtime. For example, when a user only accesses a regular form page, the dynamic rendering engine may only need to load the 1-2 shard files corresponding to the "form controls" group in the gms-plugin type, without loading the shards related to "charts" or "secondary development platforms." This greatly reduces the amount of data transmitted over the network, significantly shortens the browser's parsing and compilation time, directly improves the first-screen loading speed and page response performance, and overcomes the core defects of "resource redundancy and performance degradation" in traditional solutions.
[0149] It provides precise and efficient component addressing capabilities at runtime, supporting true "on-demand" rendering: The global index file generated by S122 provides a component query service with constant time complexity (O(1)) at runtime. When the dynamic rendering engine determines that "component A" needs to be rendered based on the form configuration, it does not need to traverse or guess; it can directly query this index to instantly know that the code of "component A" is located in the app.2.js file. Subsequently, the engine can initiate precise asynchronous loading of the file segment. This "following the map" mechanism is the key technical guarantee for realizing the dynamic rendering process of "on-demand query, loading and instantiation," ensuring high efficiency in dynamic rendering.
[0150] This architecture endows the system with flexibility and manageability: the sharding strategy (S121) ensures that the code is organized in accordance with business logic, with a clear structure that is easy to understand and maintain. The index file (S122), as a centralized addressing directory, uniformly manages the physical distribution of all components. This architecture enables incremental updates (only the affected shards and indexes need to be updated). Simultaneously, it provides flexible underlying support for more advanced optimization strategies (such as dynamically adjusting shards based on component usage frequency, preloading key shards, etc.), enhancing the system's long-term evolvability.
[0151] Based on the same inventive concept, embodiments of this application also provide a configuration method for dynamically rendering forms.
[0152] Figure 4 This is a flowchart illustrating a configuration method for dynamically rendering forms according to an embodiment of this application, as shown below. Figure 4As shown in the embodiment of this application, a configuration method for dynamically rendering forms includes:
[0153] S21. Provide a visual configuration interface and display selectable components and their configurable parameters in the interface based on a global component configuration description file;
[0154] In step S21, the global component configuration description file is generated according to the component resource library construction method for dynamic rendering described in any of the above embodiments.
[0155] Visual configuration interface: refers to a graphical, interactive web application interface (i.e., a "secondary development platform"). This interface may include areas such as a component library panel, a canvas design area, and a property configuration panel, which users can operate in an intuitive way through drag-and-drop, selection, and filling in.
[0156] Displaying optional components and their configurable parameters in the interface: This is an automated rendering process. The system parses the aforementioned global component configuration description file, based on the data within:
[0157] The corresponding component icons or list (i.e., selectable components) are rendered in the "Component Library Panel".
[0158] When a user selects a component, the form controls (such as input boxes, drop-down boxes, switches, etc.) with all configurable parameters of that component are dynamically generated in the "Property Configuration Panel" and the default values are filled in.
[0159] S22. In response to the user's component selection and parameter configuration operations on the interface, generate and store a form structure description file, which describes the component composition of the business form configured by the user and the parameter values of each component.
[0160] In step S22, the component selection and parameter configuration operation refers to the interaction performed by the user on the visual interface, such as: dragging the "Date Picker" component from the library onto the canvas (selection), and then changing its "Label" to "Date of Employment" and setting the "Format" to "YYYY-MM-DD" in the right-hand property panel (parameter configuration).
[0161] Form structure description file: This refers to the persistent storage of the final result of a series of user configuration operations. It is a structured data file (e.g., in JSON format) whose content precisely describes:
[0162] Component composition: What components make up this form, and how these components are arranged on the canvas (order, position, etc.).
[0163] Specific parameter values for each component: The specific values of all configuration items for each component (i.e., the values set by the user on the interface).
[0164] Generation and storage: The system monitors user operations in real time, and finally serializes the complete state of the current form into the above-mentioned structured file, and saves it to the server database or file system. Each business form corresponds to an independent description file.
[0165] The configuration method for dynamically rendered forms provided in this application combines "global configuration description" with "user interaction" to achieve a closed loop from data to configuration and then from configuration to data, generating disruptive business value.
[0166] This achieves complete decoupling between business logic and front-end technology, empowering business personnel: Business personnel (such as product managers and implementation consultants) can independently build and modify complex business forms on an intuitive interface without writing any code or understanding the internal implementation of components. It directly and fundamentally solves the pain points of "rigid system functionality, unable to dynamically respond to business changes" and "poor scalability." Changes in business requirements (such as adding a field or modifying validation rules) do not require waiting through development, testing, and deployment cycles, achieving responses in minutes or even seconds, greatly improving business agility.
[0167] This ensures the standardization and accuracy of the configuration process: Since the configuration interface is entirely driven by the "global component configuration description file," the options and constraints displayed to the user (such as parameter types and optional values) are standardized and accurate, avoiding ambiguity or errors that may occur with manual configuration. It eliminates the information loss and misunderstanding risks in traditional requirement transmission, guaranteeing the syntactic and semantic correctness of the final generated "form structure description file," providing reliable input for subsequent zero-error dynamic rendering.
[0168] The resulting "form structure description file" becomes the sole bridge connecting the "configuration phase" and the "runtime phase." The dynamic rendering engine's responsibility is simplified to reading and executing this file. This completely separates the form's presentation logic (engine) from the form's definition (configuration), resulting in a clearer and more stable system architecture that aligns with the core design principles of front-end / back-end separation and low-code platforms.
[0169] In summary, this configuration method transforms the global configuration description file generated during the build phase into specific, directly executable form structure description files through a visual interface.
[0170] In some embodiments, the form structure description file is a JSON format file, the contents of which include the component layout structure of the business form, the type identifiers of the included components, and the specific parameter values assigned to the configuration items of each component.
[0171] Specifically, the JSON format is structured (key-value pairs, arrays), free of redundancy, and naturally compatible with JavaScript.
[0172] The component layout structure of a business form refers to the data describing the visual arrangement and nesting relationships of various components within the form. For example, it can define the order of components in rows, columns, or grids, groupings (such as field sets or cards), and parent-child hierarchical relationships. This ensures that the dynamic rendering engine can not only render isolated components but also accurately reproduce the form's UI structure according to the overall page layout designed by the business users.
[0173] Component type identifier: This is the component identifier or component name, such as AddressPicker or DateSelector. This identifier must strictly match the identifiers recorded in the "Global Component Configuration Description File" and the "Global Component Index File." This is the "primary key" connecting the configuration and the code. At runtime, the dynamic rendering engine relies on this identifier to locate the component code in the "Global Component Index File," thereby loading the correct component implementation.
[0174] The specific parameter values assigned to each component's configuration item: These refer to the actual values set by business personnel for each configurable attribute of each component on the visual configuration interface. For example, setting the label attribute of the AddressPicker component to "Shipping Address" and the required attribute to true.
[0175] The difference between "configurable parameter set" and "specific parameter value" is that "configurable parameter set" (from emcon) defines which parameters a component can accept and their types (schema), while "specific parameter value" is the actual data (instance) filled in according to the schema.
[0176] The form structure description file, through standardized and declarative data description, achieves the following core effects: it realizes the pure datafication and persistence of business logic, supporting true "dynamics." A complete and complex business form is completely stripped of specific programming language and framework code, defined and saved in a pure data (JSON) file. This allows the form definition to exist and evolve independently of the system source code. When the form needs to be modified, only this JSON data file needs to be updated, without triggering the rebuilding and deployment of the front-end application. This directly achieves "hot-swappable" function updates, overcoming the problem of "rigid system functionality."
[0177] This ensures unambiguous and efficient transmission and parsing of configuration information: the standardized JSON format ensures that the file can be transmitted and parsed losslessly and efficiently between the secondary development platform (generator), backend storage, and dynamic rendering engine (consumer). Its structured nature allows the rendering engine to quickly and accurately extract component type identifiers and specific parameter values, just like handling ordinary data objects. This provides direct input for subsequent component lookup and instantiation, guaranteeing the reliability and high performance of the entire dynamic rendering process.
[0178] This significantly enhances component reusability and system flexibility: the same component (such as DateSelector) can be reused in countless different business forms, exhibiting different appearances and behaviors, by assigning different specific parameter values to this JSON file (such as label: "Start Date" or label: "Birthday", format: "YYYY-MM-DD" or format: "MM / DD / YYYY"). This greatly improves component reusability and avoids "reinventing the wheel" from a technical perspective. Business users can flexibly combine parameters to cope with ever-changing business scenarios, achieving the flexibility of "meeting unlimited needs with limited components".
[0179] Based on the same inventive concept, this application also provides a method for dynamically rendering forms.
[0180] Figure 5 This is a flowchart illustrating a dynamic form rendering method according to an embodiment of this application, as shown below. Figure 5 As shown in the embodiment of this application, a dynamic rendering method for a form includes:
[0181] S31. In response to an access request for the target form, obtain the form structure description file corresponding to the target form;
[0182] In step S31, the access request is usually triggered by the end user clicking a link or menu item in the browser, corresponding to a specific business function, such as "open employee onboarding form".
[0183] Retrieval: This refers to the dynamic rendering engine sending a request to the backend server and receiving the returned data. This file is the JSON file that describes the specific form, generated and stored during the configuration phase (S22).
[0184] S32. Parse the form structure description file to determine one or more target components and their corresponding instantiation configuration parameters required to render the target form;
[0185] In step S32, parsing refers to decoding and extracting data from the obtained JSON file. Through parsing, two core pieces of information are clarified:
[0186] Target components: This refers to the specific components that make up the form, which can be presented as a list of component type identifiers.
[0187] Instantiated configuration parameters: These are the specific attribute values (such as label text, default value, whether to disable, etc.) that each target component should use in this rendering. These values come from the configuration of the business personnel.
[0188] S33. Based on a global component index file, determine the component logic fragment file associated with the target component, and dynamically load the determined component logic fragment file;
[0189] In step S33, the global component index file is generated by the component resource library construction method for dynamic rendering described in any of the above embodiments. Using the component type identifier obtained from S32 as the "key", this global component index file is queried to quickly find the specific fragment file identifier (e.g., app.2.js) where the component code is located.
[0190] Dynamic loading refers to using front-end technologies (such as import() for dynamic import) to asynchronously and on-demand retrieve and execute component logic fragment files from the server. This step is the core of on-demand loading, avoiding loading all code during initialization.
[0191] S34. Based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, dynamically instantiate and render the target component to combine and present the target form.
[0192] In step S34, the component implementation code is the specific JavaScript component definition (such as Vue / React component options or classes) loaded from the shard file.
[0193] Dynamic instantiation: refers to the dynamic creation of corresponding component instances (VNodes or React elements) based on component definitions at runtime through the API of front-end frameworks (such as Vue's createComponent or React's createElement).
[0194] Rendering: The created component instance, combined with the instantiation configuration parameters obtained from S32 (injected through props, etc.), is finally mounted onto the DOM tree and presented as a visual and interactive UI element.
[0195] The dynamic form rendering method provided in this application achieves true "runtime dynamic rendering," enabling instantaneous response to business needs: the entire rendering process is driven entirely by the data file acquired at runtime, and the system does not predict the final form format at startup. This fundamentally overcomes the defect that "system functions are completely fixed during compilation and packaging." When changes in business requirements lead to updates to the form description file, the system will automatically render the new version of the form the next time the user visits, achieving true "hot updates" and "plug and play," shortening the business response cycle from "days / hours" to "seconds."
[0196] Through a sophisticated combination of "index lookup" and "dynamic loading," performance is optimized to the extreme: Step S33 is the concentrated embodiment of this solution's performance advantages. It uses indexes to address components and loads only the code fragments actually needed for the current form. This perfectly solves the performance problems of traditional solutions, such as "resource redundancy caused by pre-packaging potential needs" and "users needing to load the entire package." It ensures fast initial page load speed and high runtime resource utilization, maintaining an excellent user experience while providing rich functionality.
[0197] The completed "configuration" and "execution" loop validates the feasibility of the architecture: this method clearly demonstrates how the output of the "configuration phase" (form structure description file) is accurately consumed by the "runtime phase." It proves that the three-tier architecture (build-configure-render) of this invention is a complete, self-consistent, and working system. Every intent declared in the configuration file (component type, parameter value) can be precisely executed at runtime, enhancing the reliability and credibility of the entire technical solution.
[0198] It supports high flexibility and reusability: the same component implementation code (such as DateSelector), driven by different form description files, can be reused in different scenarios by injecting different instantiation configuration parameters, presenting different behaviors and appearances. This ensures the realization of the advantage of "high component reusability" from the operational mechanism. Developers write a general component once, and business users can combine it like building blocks to create an infinite variety of business pages, greatly reducing development costs and maintenance complexity.
[0199] like Figure 6 As shown, in some embodiments, the dynamic loading and dynamic instantiation include:
[0200] S301. Establish a global component manager during application initialization;
[0201] In step S301, during application initialization: this refers to the stage after the front-end application (main system) starts and executes the basic framework code, at which point no specific business forms have been processed.
[0202] Global Component Manager: A central registry and management object (such as a GMS object) created in memory. It is responsible for maintaining a collection of all loaded and available component definitions in the current application and provides registration and query interfaces.
[0203] S302. Determine the group of components to be loaded based on the context of the current access request;
[0204] In step S302, the context of the access request refers to the business scenario information that triggered this rendering, which can be obtained through the page URL, routing parameters, user roles, etc. For example, the access path / form / approval indicates that this is an "approval form" scenario.
[0205] Identify the component groups to be loaded: Based on context information, map the component business groups that are most likely to be needed in this scenario (e.g., the "Approval Form" scenario corresponds to the "Form Controls" and "Approval Operation Buttons" groups). This is a predictive optimization designed to prepare resources in advance.
[0206] S303. Based on the global component index file, asynchronously request and load the component logic fragment file corresponding to the component group, and register the components defined in the fragment file to the global component manager;
[0207] In step S303, asynchronous request and loading: use non-blocking methods such as fetch() or import() to load network resources, ensuring that the main thread and page rendering are not blocked.
[0208] Registering with the global component manager: After the fragment file is loaded and executed, the component definitions (constructors or option objects) contained within it will call specific APIs (such as addElements) to register themselves with the global component manager. Afterward, the component is in a "ready" state and can be instantiated.
[0209] S304. After parsing the form structure description file, query and obtain the definition of the target component through the global component manager;
[0210] In step S304, query and obtain: After parsing the form description file to obtain the specific "component type identifier" (such as DateSelector), the rendering engine no longer needs to query the network or index file, but directly requests the component definition corresponding to the identifier from the ready global component manager (such as calling GMS.getElement()).
[0211] This step transforms component lookup from a file I / O operation (index lookup, which may trigger network requests) into a memory lookup operation, which is extremely fast and is key to ensuring the efficiency of the rendering process.
[0212] S305. Utilize the dynamic component capabilities of the front-end framework, combined with the obtained component definition and the instantiation configuration parameters, to create a component instance and complete the rendering.
[0213] In step S305, the dynamic component capability of the front-end framework refers to the feature provided by modern front-end frameworks (such as Vue and React) that renders components at runtime based on their names or definitions. For example, Vue's createComponent or React's createElement(componentDefinition).
[0214] Creating a component instance: The engine combines the component definition obtained in the previous step with the instantiation configuration parameters parsed from the form description file, and calls the framework API to generate a virtual node (VNode) or React element, that is, a specific component instance with data.
[0215] Rendering complete: The framework's rendering system ultimately converts the virtual nodes into real DOM elements and mounts them into the specified container on the page.
[0216] Steps S301 to S305 separate "preloading" from "on-demand instantiation," optimizing user experience and resource utilization.
[0217] The preloading phase, consisting of S302-S303, intelligently predicts and preloads the code for potentially needed component groups based on context, putting them into a "ready" state (registered with the manager). The instantiation phase, consisting of S304-S305, then quickly retrieves and renders the components from memory once it's precisely known which ones are needed. This "prepare materials in advance, assemble quickly when needed" model avoids the "white screen" time during the initial rendering while waiting for code to load (improving first-screen performance) and ensures that not all resources are loaded blindly (maintaining the efficiency advantage of on-demand loading). It smooths the loading process, providing a more seamless user experience.
[0218] A highly efficient memory-level component service center is built through a global component manager: the global component manager (established in S301, populated in S303) serves as a memory-resident list of all available components, eliminating the overhead of repeatedly querying index files and parsing fragment files during each render. Step S304 queries directly from memory, which is much faster than file I / O, greatly reducing the rendering latency of individual components. Furthermore, once a component is loaded and registered, it can be reused an unlimited number of times in subsequent operations within the same page or session, further improving overall runtime efficiency.
[0219] A clear and reliable component acquisition and consumption contract was established: S303 (Registration) and S304 (Query) jointly define a clear interface: any component must first be registered in the manager before it can be acquired by subsequent processes. S305 defines how to use the acquired components. This makes the dynamic rendering engine's logic very simple and robust: it only needs to assume that the required components are already in the manager and focus on instantiation and rendering. This design reduces the complexity of the engine and clearly separates the responsibility of component resource management, conforming to the design principles of high cohesion and low coupling.
[0220] By fully leveraging the native capabilities of modern front-end frameworks, the feasibility and high performance of the solution are ensured: S305 explicitly states that the final instantiation and rendering are completed using the "dynamic component capabilities of the front-end framework." This avoids reinventing the wheel or using inefficient DOM manipulation methods. Built directly on the official APIs of mature frameworks such as Vue and React, the final rendered components are identical to native components in terms of performance, functionality, and ecosystem compatibility, enabling the dynamic architecture of this invention to be smoothly implemented and achieve production-grade performance.
[0221] To better understand this application, the following detailed description of a method for constructing a component resource library for dynamic rendering, a method for configuring dynamically rendering forms, and a method for dynamically rendering forms provided in this application will be provided through a specific embodiment.
[0222] This embodiment proposes a plugin-oriented form collection and rendering system. The system realizes dynamic registration, collection, management and rendering of front-end components through a plugin architecture, and supports business personnel to configure and extend form functions as needed at runtime without modifying the main system code or redeploying.
[0223] It mainly consists of the following four core modules:
[0224] 1) Plugin registration mechanism
[0225] It provides component registration specifications, including plugin type definition methods, mcon registration methods, and emcon registration methods. After the component is registered according to the specifications, it is compiled and uploaded to the npm repository.
[0226] a. Plugin type definition method
[0227] Plugins need to declare their type in the configuration file. Currently, three types are supported, distinguished by business scenarios.
[0228] gms-entry-plugin: The type of plugin that needs to be loaded for UI rendering.
[0229] gms-plugin: The type of plugin that needs to be loaded for user interface rendering.
[0230] gms-gbc-plugin: A plugin type required for secondary UI rendering.
[0231] By defining the types of plugins used in different business scenarios, unnecessary plugin loading can be reduced during dynamic rendering, thereby improving loading performance, based on business needs.
[0232] b. mcon registration method
[0233] mcon registers the business logic and interactive behavior of extended components. It supports registering components and JavaScript logic, and allows defining different groups based on business scenarios to register components into different groups. This facilitates accurate component location during dynamic rendering and reduces query time. Combined with dynamic loading, it uses methods such as `const xxx = () => import(xxx)` to reduce the package size.
[0234] c. emcon registration method
[0235] Emcon defines configuration parameters for extended components using JSON format, achieving standardized component descriptions. Component names registered in emcon must match those in mcon for easy component lookup and use during form rendering after secondary development. Different groups can be defined based on business scenarios, and these groups can be consistent with mcon. Personalized configurations can be replaced by setting configuration item priorities, improving scalability and component reusability.
[0236] 2) Component Collector
[0237] This module is key to enabling "dynamic collection" capabilities. It automatically triggers its operation during system compilation and build. Figure 7 As shown, the workflow of this module is as follows:
[0238] a. Active scanning
[0239] The extend-script script retrieves the plugin packages to be collected based on the files registered in the solution and automatically scans the plugin directory in a loop.
[0240] b. File recognition and parsing
[0241] Identify and parse the component logic file (app.js) and component configuration description file (emcon.js) that conform to the specifications in the plugin.
[0242] c. File extraction, integration, and index building
[0243] A sandbox environment was simulated to calculate the plugin package size. A strategy of evenly distributing the files resulted in six numbered files: app.js, entryPlugin.js, and the component index plugins-len.js. The emcon configurations were then merged based on priority to generate plugins-emcon.json. All generated files were then output to the application build package.
[0244] d. Execution Timing Injection
[0245] The extend-script script injects execution timing into the UI layer by modifying the compiled index.html.
[0246] 3) Secondary development platform
[0247] This module is a centralized component information display and configuration center, serving as a bridge connecting "collection" and "rendering".
[0248] Business or implementation personnel log in to the secondary development platform. The platform loads and parses plugins-emcon.json and app.0.js of type gms-gbc-plugin, displaying all available form components in a visual manner. Users can combine desired components (such as "address selector" and "date picker") into the target form by dragging and dropping. In the configuration interface, the parameters of each component can be customized (e.g., setting the default value of the "address selector" component to "Beijing"). After configuration, the platform generates a JSON file describing the form structure, component types, and specific configurations, and saves it to the backend.
[0249] It allows users to address scenarios with frequently changing business requirements through online configuration, dynamically responding to business changes without modifying code or recompiling and redeploying the program.
[0250] 4) Dynamic rendering engine
[0251] This module is the executor of the system's runtime capabilities, responsible for dynamically generating the user interface based on the configuration. For example... Figure 8 As shown, the workflow of this module is as follows:
[0252] a. Initialization
[0253] End users access pre-configured function pages (such as an approval form).
[0254] The system initializes, loads core libraries such as gms-business-libs, and establishes a global GMS management object.
[0255] b. Load on demand
[0256] When a function in an app is clicked or the homepage loads, the dynamic rendering engine determines the plugin groups to be loaded based on the current page context (e.g., loading only form components). It fully utilizes the TCP channel, loading plugin scripts in chunks to improve collection performance. For example, `addElements(item.mcon)` attaches the relevant components to the window and triggers the component's self-executing methods.
[0257] c. Configuration Analysis and Rendering
[0258] The engine requests and retrieves the form configuration JSON stored on the backend. The engine parses the JSON configuration and, based on the component type identifier, uses methods provided by GMS (such as getElement) to find and retrieve the corresponding component definition from the loaded component collection by group name. This leverages Vue's dynamic components (…). <component :is="...">This process combines modern front-end technologies such as dynamic imports (e.g., `import()`) to instantiate components. Configuration parameters, form data models, and event listeners from the JSON are injected into the component instance. Finally, the component is rendered to the specified location on the page, completing the dynamic presentation of the entire form.
[0259] Figure 9 This demonstrates the complete usage process of a "plugin-oriented form collection and rendering system," from requirement gathering to system rendering. The following section will describe this usage process using a real-world scenario.
[0260] Suppose a company needs to add a "skills assessment" form to its employee onboarding process. Traditionally, this requires front-end developers to code, test, and deploy, resulting in a lengthy process. After adopting this system:
[0261] Developers can pre-develop a "skill rating" plugin (including star rating UI and logic) and release it.
[0262] This plugin is automatically collected during system build.
[0263] On the secondary development platform, the implementers drag and drop the "Skill Rating" component into the onboarding form, set parameters such as a maximum score of 5 stars and required fields, and save to generate a configuration JSON.
[0264] When new employees fill out the onboarding form, the system dynamically loads and renders the "skills assessment" component, without requiring the main system to be republished.
[0265] This embodiment constructs a complete "plugin-oriented form collection and rendering system," achieving a closed-loop process from dynamic registration of front-end components, automated collection, visual configuration to runtime on-demand rendering. Compared to traditional front-end development models and existing component-based solutions, this invention has the following significant advantages:
[0266] 1) Achieve true dynamic expansion and hot-swapping
[0267] The system utilizes a plug-in architecture and a runtime dynamic rendering engine to enable "plug-and-play" new features without modifying the main system code or rebuilding and redeploying. Business users can quickly configure and publish new forms through the secondary development platform, greatly shortening the demand response cycle and effectively addressing the challenges of frequent business changes.
[0268] 2) Improve system scalability and openness
[0269] Through standardized plugin interfaces (mcon / emcon) and a group management mechanism, the system supports third-party developers in independently developing and publishing plugins, which can then be integrated into the main system. This creates an open and ecosystem-based front-end extension platform, breaking down system functional boundaries and supporting collaborative development across teams and business lines.
[0270] 3) Significantly improves component reuse rate and reduces development and maintenance costs.
[0271] The system achieves unified management and visual display of component resources through a component collector and standardized descriptions (emcon). Business users can directly reuse existing components, avoiding "reinventing the wheel." Developers only need to focus on encapsulating business logic, significantly improving development efficiency and reducing code redundancy and maintenance complexity.
[0272] 4) Optimize resource loading performance and improve user experience.
[0273] During the build phase, the system segments and merges plugins as needed. At runtime, it dynamically loads the required component scripts based on the context, avoiding an excessively large initial package. It fully leverages browser caching and TCP concurrency to reduce unnecessary network requests, improving first-screen loading speed and runtime performance.
[0274] 5) Supports fine-grained permission and scenario-based management
[0275] By using plugin types (gms-entry-plugin, gms-plugin, gms-gbc-plugin) and grouping mechanisms, the system can accurately load plugins according to different business scenarios, avoiding resource waste. At the same time, it supports setting the priority of configuration items to meet personalized business needs.
[0276] 6) Improve system maintainability and architectural clarity
[0277] The system separates component development, collection, configuration, and rendering, with clearly defined responsibilities for each module and a well-defined architecture. This facilitates team collaboration, system upgrades, and troubleshooting, aligning with the modern trends of front-end engineering and microservices.
[0278] This application also provides a component resource management device, specifically including a component resource library construction device for dynamic rendering, a configuration device for dynamically rendering forms, and a dynamic rendering device for forms.
[0279] Figure 10 This is a schematic diagram of a component resource library construction device for dynamic rendering provided in an embodiment of this application, as shown below. Figure 10 As shown in the embodiment of this application, a component resource library construction device for dynamic rendering includes:
[0280] The first parsing module 41 is used to scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package includes a component logic file defined using a first registration method and a component configuration description file defined using a second registration method;
[0281] The first generation module 42 is used to perform sharding processing on the logic code of the component based on the parsing results, and generate a global component index file that records the mapping relationship between the component and the shard file;
[0282] The second generation module 43 is used to merge the component configuration description files of all plugins to generate a unified global component configuration description file. The global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime.
[0283] Figure 11 This is a schematic diagram of the structure of a configuration device for dynamically rendering forms according to an embodiment of this application, as shown below. Figure 11 As shown in the embodiment of this application, a configuration device for dynamically rendering forms includes:
[0284] The display module 51 is used to provide a visual configuration interface and, based on a global component configuration description file, display the optional components and their configurable parameters in the interface.
[0285] The third generation module 52 is used to generate and store a form structure description file in response to the user's component selection and parameter configuration operations on the interface. The form structure description file is used to describe the component composition of the business form configured by the user and the parameter values of each component.
[0286] Figure 12 This is a schematic diagram of the structure of a dynamic rendering device for a form provided in an embodiment of this application, as shown below. Figure 12 As shown in the embodiment of this application, a dynamic rendering apparatus for a form includes:
[0287] The acquisition module 61 is used to acquire the form structure description file corresponding to the target form in response to the access request for the target form;
[0288] The second parsing module 62 is used to parse the form structure description file and determine one or more target components and their corresponding instantiation configuration parameters required to render the target form;
[0289] Loading module 63 is used to determine the component logic fragment file associated with the target component based on a global component index file, and dynamically load the determined component logic fragment file;
[0290] The instantiation and rendering module 64 is used to dynamically instantiate and render the target component based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, so as to combine and present the target form.
[0291] The embodiments of the apparatus provided in this application can be used to execute the processing flow of the corresponding method embodiments described above. Its functions will not be repeated here, but can be referred to the detailed description of the method embodiments described above.
[0292] Figure 13 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application, as shown below. Figure 13 As shown, the electronic device may include a processor 701, a communications interface 702, a memory 703, and a communication bus 704, wherein the processor 701, the communications interface 702, and the memory 703 communicate with each other via the communication bus 704. The processor 701 may call logical instructions in the memory 703 to execute the methods described in any of the above embodiments.
[0293] Furthermore, the logical instructions in the aforementioned memory 703 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part 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 application. 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.
[0294] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments.
[0295] This embodiment provides a computer-readable storage medium storing a computer program that causes the computer to perform the methods provided in the above-described method embodiments.
[0296] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0297] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0298] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0299] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0300] In the description of this specification, the references to "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0301] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.< / component>
Claims
1. A method for managing component resources, characterized in that, The method includes: Scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package contains a component logic file defined using a first registration method and a component configuration description file defined using a second registration method; Based on the parsing results, the logic code of the component is split into fragments, and a global component index file is generated that records the mapping relationship between the component and the fragment file. Merge the component configuration description files of all plugins to generate a unified global component configuration description file. The global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime. The process of identifying and parsing plugin packages conforming to a preset format includes: Identify the business scenario types of the components declared in the plugin package; Parse the component logic file to obtain the registered component implementation code and the business group information to which the component belongs; The component configuration description file is parsed to obtain a set of configurable parameters for the component defined by structured data, wherein the component identifier defined in the component configuration description file is associated with the component identifier registered in the component logic file.
2. The method according to claim 1, characterized in that, Based on the parsing results, the logic code of the component is segmented, and a global component index file recording the mapping relationship between the component and the segmented files is generated, including: Based on the component business scenario type and / or the business grouping information, the parsed component implementation code is divided to generate multiple component logic shard files; Create a global component index file, which records the correspondence between each component identifier and the component logical segment file in which it resides.
3. The method according to claim 1, characterized in that, The method further includes: A visual configuration interface is provided, and based on the global component configuration description file, the interface displays the optional components and their configurable parameters. In response to the user's component selection and parameter configuration operations on the interface, a form structure description file is generated and stored. The form structure description file is used to describe the component composition of the business form configured by the user and the parameter values of each component.
4. The method according to claim 3, characterized in that, The form structure description file is a JSON format file, and its content includes the component layout structure of the business form, the type identifiers of the included components, and the parameter values assigned to the configuration items of each component.
5. The method according to claim 3 or 4, characterized in that, The method includes: In response to an access request for a target form, obtain the form structure description file corresponding to the target form; Parse the form structure description file to determine one or more target components and their corresponding instantiation configuration parameters required to render the target form; Based on the global component index file, determine the component logic fragment file associated with the target component, and dynamically load the determined component logic fragment file; Based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, the target component is dynamically instantiated and rendered to combine and present the target form.
6. The method according to claim 5, characterized in that, The dynamic loading and dynamic instantiation include: A global component manager is established during application initialization; Determine the group of components to be loaded based on the context of the current access request; Based on the global component index file, asynchronously request and load the component logic shard file corresponding to the component group, and register the components defined in the shard file to the global component manager; After parsing the form structure description file, the definition of the target component is queried and obtained through the global component manager; By leveraging the dynamic component capabilities of the front-end framework, and combining the obtained component definition with the instantiation configuration parameters, a component instance is created and rendered.
7. A component resource management device, characterized in that, The device includes: The first parsing module is used to scan predefined plugin sources, identify and parse plugin packages that conform to a preset format, wherein the plugin package includes a component logic file defined using a first registration method and a component configuration description file defined using a second registration method; The first generation module is used to perform sharding of the component's logic code based on the parsing results, and generate a global component index file that records the mapping relationship between the component and the shard file; The second generation module is used to merge the component configuration description files of all plugins to generate a unified global component configuration description file. The global component index file and the global component configuration description file are used to support dynamic configuration and on-demand rendering of forms at runtime. The process of identifying and parsing plugin packages conforming to a preset format includes: Identify the business scenario types of the components declared in the plugin package; Parse the component logic file to obtain the registered component implementation code and the business group information to which the component belongs; The component configuration description file is parsed to obtain a set of configurable parameters for the component defined by structured data, wherein the component identifier defined in the component configuration description file is associated with the component identifier registered in the component logic file.
8. The apparatus according to claim 7, characterized in that, The device further includes: The display module provides a visual configuration interface and displays selectable components and their configurable parameters in the interface based on the global component configuration description file. The third generation module is used to generate and store a form structure description file in response to the user's component selection and parameter configuration operations on the interface. The form structure description file is used to describe the component composition of the business form configured by the user and the parameter values of each component.
9. The apparatus according to claim 8, characterized in that, The device further includes: The acquisition module is used to acquire the form structure description file corresponding to the target form in response to an access request for the target form; The second parsing module is used to parse the form structure description file and determine one or more target components and their corresponding instantiation configuration parameters required to render the target form; The loading module is used to determine the component logic fragment file associated with the target component based on a global component index file, and dynamically load the determined component logic fragment file; The instantiation and rendering module is used to dynamically instantiate and render the target component based on the component implementation code in the loaded component logic fragment file and the instantiation configuration parameters, so as to combine and present the target form.
10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.