Reusable front-end resource construction method, reusable front-end resource application creation method, reusable front-end resource application creation equipment, storage medium and program product

Abstract

The embodiment of the invention provides a reusable front-end resource construction method and device, a reusable front-end resource application creation method and device, a storage medium and a program product. The reusable front-end resource construction method comprises the following steps: acquiring a dependency directory configured in a single-warehouse multi-module architecture; wherein the dependency directory comprises a plurality of UMD modules; obtaining a mapping relation between a relative path and a global variable of each UMD module; dynamically loading a to-be-called UMD module of the front-end resource according to a construction instruction of the reusable front-end resource and the mapping relation by utilizing a global variable agent; and generating the front-end resource based on the plurality of loaded UMD modules. The front-end resources obtained through the method are dynamically loaded and dependent on demand, cross-framework application can be achieved, lightweight application can be achieved, and application performance can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a reusable front-end resource construction, application creation method, device, storage medium and program product. Background Art

[0002] The low-code platform provides an efficient and low-cost way to build applications. Users only need to drag and drop the components provided by the low-code platform to complete the application layout.

[0003] Other systems also hope to achieve capabilities similar to those provided by low-code platforms, enabling application development through simple operations on resource-provided functions. Currently, in application development, dependencies can be used to utilize the functions provided by resources for application development. However, excessive dependencies can lead to application redundancy and poor performance. Summary of the Invention

[0004] The embodiments of the present application provide a reusable front-end resource construction, application creation method, device, storage medium and program product, which are used to generate reusable front-end resources across frameworks and dynamically load dependencies on demand, thereby achieving lightweight applications built based on them and improving the performance of the built applications.

[0005] In a first aspect, an embodiment of the present application provides a reusable front-end resource construction method, comprising:

[0006] Obtain a dependency directory configured in a single-repository multi-module architecture; wherein the dependency directory includes multiple UMD modules;

[0007] Obtaining the mapping relationship between the relative path of each UMD module and the global variable;

[0008] According to the construction instructions of the reusable front-end resources, the UMD module to be called by the front-end resources is dynamically loaded using the global variable proxy according to the mapping relationship;

[0009] The front-end resources are generated based on the loaded multiple UMD modules.

[0010] In a possible implementation, dynamically loading the UMD module to be called by the front-end resource according to the construction instruction of the reusable front-end resource and using the global variable proxy according to the mapping relationship includes:

[0011] For any call request to a UMD module to be called, call the global variable proxy to intercept the call request;

[0012] Utilize the global variable proxy to traverse the global variables exposed by the loaded UMD module, and determine whether the UMD module to be called has been loaded according to the traversal result;

[0013] In response to determining that the UMD module to be called is not loaded, an absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path.

[0014] In one possible implementation, the dependency directory configured in the single-warehouse multi-module architecture is obtained based on the following steps:

[0015] Create dependent configuration items according to preset operations, where the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items, and page dependent configuration items;

[0016] According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to a UMD format to obtain a UMD module corresponding to each dependency.

[0017] In a possible implementation, the dependent configuration item includes an external dependent configuration item;

[0018] The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes:

[0019] According to the received external dependency configuration operation, an external dependency is configured for the external dependency configuration item, and the output of the external dependency is set to UMD format to obtain a third-party UMD module corresponding to the external dependency; the external dependency includes a first dependency resource from a third party.

[0020] In a possible implementation, the dependent configuration item includes an internal dependent configuration item, and the method further includes:

[0021] Creating a first source code for a function shared within the front-end resource;

[0022] Invoking a preset construction tool to construct the first source code into a second dependency resource corresponding to the internal dependency according to a preset format; and

[0023] The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes:

[0024] According to the received internal dependency configuration operation, an internal dependency is configured for the internal dependency configuration item, and the output of the internal dependency is configured in a UMD format to obtain an internal UMD module corresponding to the internal dependency; wherein the internal dependency includes a corresponding second dependency resource.

[0025] In a possible implementation, the dependency configuration item includes a page dependency configuration item, and the method further includes:

[0026] Creating a second source code corresponding to at least one page of the front-end resource;

[0027] Invoking a preset construction tool to construct the second source code corresponding to each of the pages into a third dependency resource corresponding to the page dependency according to a preset format; and

[0028] The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes:

[0029] According to the received page dependency configuration operation, at least one page dependency is set in the page configuration item; and the output of each page dependency is set to UMD format to obtain a page UMD module corresponding to each page; wherein each page dependency includes a corresponding third dependency resource.

[0030] In one possible implementation, the method further includes:

[0031] According to the sandbox environment packaging instruction, an isolated sandbox is packaged for the front-end resources, and the isolated sandbox is used to avoid dependency conflicts between different front-end resources.

[0032] In a possible implementation, encapsulating an isolated sandbox for the front-end resources according to the sandbox environment encapsulation instruction includes:

[0033] Creating an independent sandbox environment according to the sandbox environment packaging instructions;

[0034] Initialize the srcdoc attribute of the sandbox environment and provide a mounting entry for the front-end resources;

[0035] Loading a sandbox environment, and dynamically loading the front-end resources after the sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window in the sandbox is returned for calling through a callback function.

[0036] In a possible implementation, the front-end resource further includes a parameter injection entry, wherein the parameter injection entry is used to receive data to be processed by the front-end resource; the data to be processed includes data obtained across domains by an application program within which the front-end resource is applied.

[0037] In a possible implementation, the front-end resources are resources packaged as an SDK.

[0038] In a second aspect, an embodiment of the present application provides an application creation method, including:

[0039] Receiving a call instruction for a front-end resource during application development; the parameters indicated by the call instruction include a mounting element, a display style, and a target function to be called; wherein the front-end resource is created by the reusable front-end resource construction method provided by the first aspect and various possible implementations;

[0040] Passing the parameters into the front-end resource;

[0041] Receive an access interface for the target function instance returned by the callback function corresponding to the front-end resource;

[0042] Displaying the running result of the target function instance obtained by accessing the access interface in the display style at the position corresponding to the mounting element; the target function instance is generated by the front-end resource according to the target function;

[0043] The application is created based on the running result of the target function instance.

[0044] In some possible implementations, the front-end resource is a front-end resource encapsulated in an isolated sandbox; and the step of transferring the parameter to the front-end resource includes:

[0045] The parameters are transmitted to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein the front-end resource running in the isolated sandbox monitors parameter transmission events and obtains the parameters from the monitored parameter events; and the access interface for receiving the target function instance returned by the callback function corresponding to the front-end resource includes:

[0046] Receive the target function instance access interface returned by the callback function corresponding to the front-end resource through the preset secure cross-domain communication mechanism.

[0047] In a third aspect, an embodiment of the present application provides a reusable front-end resource construction device, comprising:

[0048] A first receiving module is configured to obtain a dependency directory configured in a single-repository multi-module architecture; wherein the dependency directory includes multiple UMD modules;

[0049] A first acquisition module is used to obtain a mapping relationship between the relative path of each UMD module and the global variable;

[0050] A first loading module is used to dynamically load the UMD module to be called by the front-end resource according to the construction instruction of the reusable front-end resource and the mapping relationship using a global variable proxy;

[0051] The first generating module is used to generate the front-end resources based on the loaded multiple UMD modules.

[0052] In a possible implementation manner, the first loading module is specifically configured to:

[0053] For any call request to a UMD module to be called, call the global variable proxy to intercept the call request;

[0054] Utilize the global variable proxy to traverse the global variables exposed by the loaded UMD module, and determine whether the UMD module to be called has been loaded according to the traversal result;

[0055] In response to determining that the UMD module to be called is not loaded, an absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path.

[0056] In one possible implementation, the apparatus further includes a dependency configuration module, which determines the dependency directory configured in the single-warehouse multi-module architecture based on the following steps:

[0057] Create dependent configuration items according to preset operations, where the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items, and page dependent configuration items;

[0058] According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to a UMD format to obtain a UMD module corresponding to each dependency.

[0059] In a possible implementation, the dependent configuration item includes an external dependent configuration item;

[0060] The dependency configuration module is specifically used for:

[0061] According to the received external dependency configuration operation, an external dependency is configured for the external dependency configuration item, and the output of the external dependency is set to UMD format to obtain a third-party UMD module corresponding to the external dependency; the external dependency includes a first dependency resource from a third party.

[0062] In a possible implementation, the dependency configuration item includes an internal dependency configuration item, and the apparatus further includes an internal dependency construction module, wherein the internal dependency construction module is configured to:

[0063] Creating a first source code for a function shared within the front-end resource;

[0064] Invoking a preset construction tool to construct the first source code into a second dependency resource corresponding to the internal dependency according to a preset format; and

[0065] The dependency configuration module is specifically used for:

[0066] According to the received internal dependency configuration operation, an internal dependency is configured for the internal dependency configuration item, and the output of the internal dependency is configured in a UMD format to obtain an internal UMD module corresponding to the internal dependency; wherein the internal dependency includes a corresponding second dependency resource.

[0067] In a possible implementation, the dependency configuration item includes a page dependency configuration item, and the apparatus further includes a page dependency construction module, wherein the page dependency construction module is configured to:

[0068] Creating a second source code corresponding to at least one page of the front-end resource;

[0069] Invoking a preset construction tool to construct the second source code corresponding to each of the pages into a third dependency resource corresponding to the page dependency according to a preset format; and

[0070] The dependency configuration module is specifically used to: set at least one page dependency in the page configuration item according to the received page dependency configuration operation; and set the output of each page dependency to UMD format to obtain a page UMD module corresponding to each page; wherein each page dependency includes a corresponding third dependency resource.

[0071] In a possible implementation, the device further includes a sandbox encapsulation module, where the sandbox encapsulation module is configured to:

[0072] According to the sandbox environment packaging instruction, an isolated sandbox is packaged for the front-end resources, and the isolated sandbox is used to avoid dependency conflicts between different front-end resources.

[0073] In a possible implementation, the sandbox encapsulation module is specifically configured to:

[0074] Creating an independent sandbox environment according to the sandbox environment packaging instructions;

[0075] Initialize the srcdoc attribute of the sandbox environment and provide a mounting entry for the front-end resources;

[0076] Loading a sandbox environment, and dynamically loading the front-end resources after the sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window in the sandbox is returned for calling through a callback function.

[0077] In a possible implementation, the front-end resource further includes a parameter injection entry, wherein the parameter injection entry is used to receive data to be processed by the front-end resource; the data to be processed includes data obtained across domains by the main application within which the front-end resource is applied.

[0078] In a possible implementation, the front-end resources are resources packaged as an SDK.

[0079] In a fourth aspect, an embodiment of the present application provides an application creation device, comprising:

[0080] A second receiving module is configured to receive a call instruction for a front-end resource during application development; the call instruction indicates parameters including a mount element, a display style, and a target function to be called; wherein the front-end resource is created by the apparatus described in the third aspect and various possible implementations;

[0081] A parameter transmission module, used to transfer the parameters to the front-end resources;

[0082] A third receiving module is used to receive an access interface of a target function instance returned by a callback function corresponding to the front-end resource;

[0083] A display module is configured to display the running result of the target function instance obtained by accessing the access interface in the display style at the position corresponding to the mounting element; the target function instance is generated by the front-end resource according to the target function;

[0084] An application creation module is used to create the application program based on the running result of the target function instance.

[0085] In a possible implementation, the front-end resource is a front-end resource encapsulated in an isolated sandbox; and the parameter transmission module is specifically configured to:

[0086] The parameters are transmitted to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein the front-end resources running in the isolated sandbox monitor parameter transmission events and obtain the parameters from the monitored parameter events; and the second receiving module is specifically configured to:

[0087] Receive the target function instance access interface returned by the callback function corresponding to the front-end resource through the preset secure cross-domain communication mechanism.

[0088] In a fifth aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor;

[0089] The memory stores computer-executable instructions;

[0090] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the first aspect, the second aspect and / or various possible implementations of the first aspect and the second aspect as described above.

[0091] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement various possible implementations of the first aspect, the second aspect, and / or the first and second aspects above.

[0092] In a seventh aspect, an embodiment of the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements various possible implementations of the first aspect, the second aspect, and / or the first and second aspects above.

[0093] The reusable front-end resource construction, application creation method, device, storage medium, and program product provided in the embodiments of the present application support both the construction of common applications and the construction of SDKs by using a single-repository multi-module model to build an architecture. UMD modularization is used to build dependencies to achieve dynamic dependency loading, so that the created front-end resources are compatible with different frameworks and can be applied to any page without restrictions on the number of third-party dependencies. On-demand loading is supported, redundancy can be reduced, and applications can be lightweight, which is conducive to improving application performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0094] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0095] Figure 1 Schematic diagram of the process of building a reusable front-end resource provided by this application Figure 1 ;

[0096] Figure 2 Schematic diagram of the process of building a reusable front-end resource provided by this application Figure 2 ;

[0097] Figure 3 A flowchart of the application creation method provided for this application;

[0098] Figure 4 This is a schematic diagram of an application scenario;

[0099] Figure 5A schematic diagram of the structure of the reusable front-end resource construction device provided by this application;

[0100] Figure 6 A schematic diagram of the structure of the application creation device provided by this application;

[0101] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application.

[0102] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0103] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. When the following description refers to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present application.

[0104] First, let’s explain the terms involved in this application:

[0105] An inline frame (iframe) is an HTML tag used to embed another independent HTML document within the current web page, creating a "webpage within a web page." It offers the following advantages: good isolation, with the embedded content maintaining its own browsing context (window, DOM, and JavaScript environment); and low cross-origin restrictions, subject to the same-origin policy (communication via CORS or postMessage is possible).

[0106] Micro Frontends is a front-end architecture pattern that splits a large front-end application into multiple small front-end applications (called "micro applications") that are independently developed, deployed, and run independently, and then combined into a complete application in some way.

[0107] A software development kit (SDK) is a set of development tools that helps developers quickly build applications for specific platforms or services. These tools include: precompiled code libraries (such as API wrappers); development documentation (user guides, API references); sample code (demo projects); debugging tools (simulators, log analyzers); and necessary dependencies (compilers, runtimes).

[0108] UMD modules (Universal Module Definition modules) output code blocks in the UMD format. UMD modules are globally accessible.

[0109] The UMD format is a universal JavaScript module definition specification designed to allow the same code to run in multiple environments simultaneously, solving the problem of incompatibility of JavaScript modularization solutions and achieving "write once, run everywhere".

[0110] Iframe isolation sandbox (Sandbox Isolation) is achieved through the HTML5 sandbox attribute <iframe>A secure, isolated environment created to limit the permissions of embedded content, preventing malicious code from affecting the parent page or the user's system.

[0111] A monorepo is a code management strategy that stores multiple related projects or modules in the same version control repository. Its core features include: all projects in a single code repository share a common root directory; multiple modules coexist, allowing independent modules to be developed, tested, and deployed independently; shared dependencies, allowing for unified management of third-party library versions; and atomic commits, allowing cross-module changes to be submitted simultaneously.

[0112] Relative path, in a single repository multi-module architecture, describes the path from the dependency directory root node to the specific UMD module file.

[0113] Global variables are the interface names exposed by the UMD module in the browser environment through the window object. The module content is globally accessible through these variables. A proxy for global variable configuration is a technology that intercepts and encapsulates access to global variables to implement security control, dependency isolation, or on-demand loading. Its core goal is to solve the pollution, conflict, and uncontrollable problems of global variables while providing more flexible runtime management capabilities.

[0115] CSS (Cascading Style Sheets) file: a text file used to define the style and layout of a web page. Its extension is .css (for example, style.css). It is a specific implementation file of the Cascading Style Sheet and is used in conjunction with HTML to control the appearance and layout of a web page.

[0116] JSON (JavaScript Object Notation) file: is a lightweight data storage and exchange format file with the extension .json (e.g. data.json).

[0117] In some application scenarios, users can use terminal devices to develop applications. During the application development process, various development frameworks can be used to write codes that complete different functions. The above application development process requires a large workload for developers and results in low application development efficiency. In some application scenarios, the functions that have been created can be embedded in the page using a method that is directly integrated through iframe and micro front - end. This method is too redundant and also needs to solve problems such as deployment, network connection, and cross-domain.In some application scenarios , some reusable functions are encapsulated as components, but these functional components are limited by specific technical frameworks. Components developed in a technical framework cannot be applied to applications developed by other technical frameworks.

[0120] For functions encapsulated as JavaScript SDKs, they are usually applied to specific function libraries without dependencies. When the functions are complex, the file size is too large, which will affect the performance of the application. When the SDK has many dependencies, the SDK dependencies and the application's own dependency versions may be different, and there may be variables or functions with the same name, leading to conflicts and errors. In conjunction with the above -mentioned scene, it is known that in the prior art, by directly integrating the existing function into the page in the application development process, there is redundancy, and it is necessary to solve the problems such as deployment, network connection and cross-domain, and in addition, the compatibility of components across frameworks is poor. SDK is easy to cause poor performance due to the dependence that needs to be loaded.

[0122] The solution provided by this application sets UMD modular dependencies by using a single-warehouse multi-module model to build an architecture, and dynamically loads dependencies, so that the created front-end resources can be compatible with different application environments. The above-mentioned front-end resources support on-demand loading, which can reduce redundancy and lightweight applications.

[0123] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below with reference to the accompanying drawings.

[0124] Figure 1 is a flowchart of the reusable front-end resource construction method provided by this application. As shown in Figure 1, this method includes:

[0125] S101. Obtain the dependency directory configured in the single repository multi-module architecture; where the dependency directory includes multiple UMD modules.

[0126] In this embodiment, the execution subject of the reusable front-end resource construction method can be various electronic devices, such as terminal devices or servers, etc.

[0127] In the single repository multi-module architecture, the dependency directory is a dedicated storage area for centralized management of shared UMD modules.

[0128] In some examples, the above execution subject can receive the dependency directory set by the user in the single repository multi-module architecture in real time. In these examples, the user can configure each dependency in the dependency directory in the interface of the single repository multi-module architecture. For example, multiple UMD modules in the dependency directory can be configured using a flattened or grouped sub-directory structure from the root directory of the single repository multi-module architecture.

[0129] In some examples, the above execution subject can obtain the dependency directory from the pre-stored single repository multi-module architecture. In the existing single repository multi-module architecture, the dependency directory exists as a predefined static configuration. The above dependency directory can be obtained from the configuration file of the single repository multi-module architecture.

[0130] The dependency directory here can include multiple modules, and each module can be a UMD module. A UMD module refers to a module whose output is in the UMD form.

[0131] S102: Obtain the mapping relationship between the relative path and the global variable of each UMD module.

[0132] The relative path of a UMD module refers to a non-absolute path that points to the UMD module file based on the directory where the current file is located.It is typically used to specify the file location when dynamically loading modules. Its format is the same as a relative path for ordinary files. The module.umd.js file in the current directory uses the same directory as . / module.umd.js. The module.umd.js file in the parent directory uses the parent directory .. / libs / module.umd.js. The module.umd.js file in the dist subdirectory of the current directory uses the subdirectory dist / module.umd.js.

[0133] The mapping relationship here refers to the correspondence between the physical storage path (relative path) of the UMD module and the global variable name exposed at runtime under the single-repository multi-module architecture. In some examples, a user can set a mapping relationship between a relative path and a global variable for one or more UMD modules in a dependency directory. The mapping relationships of the multiple UMD modules can be located in separate files under the dependency directory or the root directory. In these examples, the execution entity can directly read the mapping relationships corresponding to the respective UMD modules in the above files. In some examples , the execution entity may automatically scan a dependent directory and, upon discovering a UMD module in the dependent directory, read the global variables corresponding to the UMD module from the file header corresponding to the UMD module; and then automatically generate a mapping relationship between the relative path of the UMD module and the global variables. The obtained mapping relationship corresponding to the UMD module may be cached.

[0136] S103: According to the construction instructions of the reusable front-end resources, the UMD module to be called by the front-end resources is dynamically loaded using the global variable proxy according to the mapping relationship. In some examples , the above-mentioned construction instructions can be issued by the user. In these embodiments, after the user configures the dependency directory, the above-mentioned mapping relationship of each UMD module in the dependency directory can be determined. After receiving the user's construction instructions for the reusable front-end resources, a global variable proxy instance (a proxy instance of the window object) can be created according to the above-mentioned mapping relationship. The global variable proxy is utilized to realize that the UMD modules to be called by the front-end resources are all loaded on demand.

[0138] S104: Generate front-end resources based on the loaded multiple UMD modules.

[0139] The above-mentioned execution entity can integrate multiple loaded UMD modules to obtain reusable front-end resources.Specifically, the execution entity can construct a complete dependency graph based on the loaded UMD modules, identify the export interface of each UMD module, analyze the dependencies between the modules, and determine the loading and initialization order of the modules. The execution entity performs scope isolation and conflict resolution to ensure that the global variables of each module do not conflict with each other and correctly reference each module through the previously established mapping relationship. Finally, the module code is merged according to the dependency order, unused code is removed, and finally one or more packaged files (such as .JS files) are generated.

[0141] The front-end resources generated by the solution provided by this embodiment can be a micro front-end.

[0142] In some embodiments, the generated front-end resources may be resources encapsulated as an SDK.

[0143] By encapsulating the front-end resources into an SDK (Software Development Kit), a clear API (Application Programming Interface), configuration items and documents can be provided through the SDK, thereby unifying the access specifications. When using the front-end resources, you only need to introduce the SDK to use the micro-application without having to worry about the underlying implementation, which can improve collaboration efficiency and system maintainability.

[0144] In this embodiment, by configuring a dependency directory in a single warehouse multi-module mode construction architecture, the dependencies in the dependency directory are UMD modules, which can ensure the compatibility of modules in different environments; in addition, the single warehouse multi-module mode architecture can enforce physical isolation, each module has a clear boundary, and the topological relationship of all modules is centrally managed through the dependency directory; in addition, by establishing a mapping relationship between the relative path of the UMD module and the global variable, logical isolation is achieved; using the global variable proxy mapping, a standard communication mechanism between modules can be systematically established. When a front-end resource construction instruction is received, the global variable proxy mechanism is used to dynamically load the UMD module to be called, thereby achieving dynamic on-demand loading of the UMD module, which can solve the resource loading performance bottleneck caused by the excessive volume of the monomer package due to a single loading of all dependencies, or the excessive resource demand caused by too many dispersed requests. Through this solution, a front-end resource that is less redundant, lightweight, and compatible with different development environments can be obtained. The application developed using the front-end resources provided by this solution can reduce redundancy, lightweight application, and help improve the performance of the application.

[0145] In some optional implementations, the above step S103 includes the following sub-steps:

[0146] First, for a call request to any UMD module to be called, the global variable proxy is called to intercept the call request.

[0147] In some examples, the UMD module to be called in the front-end resource may be determined by a build instruction. Schematically, the build instruction may indicate one or more UMD modules that the reusable front-end resource needs to call.

[0148] In some examples, the multiple modules of the dependency directory configured in the above-mentioned single-warehouse multi-module architecture are all used as UMD modules required by the front-end resources.

[0149] When the execution subject receives a call request for any UMD module to be called during the process of building the front-end resources, it calls the global variable proxy to intercept the call request.

[0150] Secondly, the global variable agent is used to traverse the global variables exposed by the loaded UMD module, and whether the UMD module to be called has been loaded is determined based on the traversal result.

[0151] Each loaded UMD module will expose the corresponding global variables to the global system.

[0152] In one example, the global variable agent can obtain the module identifier (such as the relative path) of the UMD module to be called from the call request, and then determine whether the UMD module to be called exists from the above mapping relationship. If the UMD module to be called is present in the mapping relationship, the global variables exposed by one or more loaded UMD modules may be traversed to determine whether the global variables corresponding to the UMD module to be called are present. In some examples , when a UMD module is loaded, it actively registers its instance with a central registry, which stores metadata (including version, dependencies, and global variables, etc.) of the UMD module. In these examples, the global variable agent may traverse the global variables exposed by the loaded UMD modules in the central registry to determine whether the global variables corresponding to the UMD module to be called are present.

[0154] If it is determined that the global variables exposed by the loaded UMD module include the global variables corresponding to the UMD module to be called, then the UMD module to be called has been loaded and does not need to be loaded again.

[0155] If it is determined that the global variables exposed by the loaded UMD module do not include the global variables corresponding to the UMD module to be called, then the UMD module to be called has not been loaded.

[0156] Finally, in response to determining that the UMD module to be called is not loaded, the absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path. The execution subject may obtain from the global variable proxy whether the UMD module to be called has been loaded. If the information obtained from the global variable proxy indicates that the UMD module to be called has not been loaded, the absolute path may be determined based on the relative path of the UMD module to be called. The absolute path may be determined by comparing the reference path with the relative path of the UMD module to be called.

[0158] In these implementations, a global variable proxy is used to intercept the call request of the UMD module to be called. The UMD module to be called is loaded only when it is determined from the global variables exposed by the loaded UMD modules that the UMD module to be called has not been loaded. This realizes the dynamic loading of UMD modules according to the global variable proxy, which can solve the dependency conflict problem of multi-version front-end resources. Dynamically loading UMD modules on demand can reduce redundant requests and can adapt to complex deployment and application in different development framework environments.

[0159] In some optional implementations of this embodiment, the dependency directory configured in the above-mentioned single warehouse multi-module architecture is obtained based on the following steps:

[0160] First, dependent configuration items are created according to preset operations, and the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items and page dependent configuration items. Dependence here refers to the relationship that a module (or project) needs external code to run normally. Usually includes external dependency, internal dependency and page dependency.

[0162] The above-mentioned dependency configuration items may include any one or more of external dependency configuration items, internal dependency configuration items and page dependency configuration items.

[0163] In these implementations, users can perform preset operations in the interface of the single-warehouse multi-module architecture. The above-mentioned preset operations can be, for example, various operations for creating dependent directory structures, or various operations for adding new dependencies to existing dependent directory structures.

[0164] Secondly, according to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to the UMD format to obtain the UMD module corresponding to each dependency.

[0165] The dependent configuration operation here can be performed by the user or automatically performed by the above-mentioned execution subject according to preset instructions.

[0166] The dependency configuration operation can configure one or more dependencies in the dependency configuration item. Schematically, for example, an identifier, source code, JSON file package, etc. corresponding to a dependency can be set in the dependency configuration item, and then the output of the dependency is set to UMD format to obtain the UMD module corresponding to the dependency.

[0167] In a single-repository multi-module architecture, dependency management tools and module packaging tools can be combined to configure one or more corresponding UMD modules for dependent configuration items.

[0168] In these implementations, regardless of external dependency, internal dependency or page dependency, they are all output in UMD format, which can eliminate module system differences and ensure the consistency of the output format.

[0169] In these embodiments, by configuring dependencies for one or more of the external dependency configuration items, internal dependency configuration items, and page dependency configuration items according to the dependency configuration operation, and setting the output of the dependency to the UMD format to obtain the corresponding UMD module, the differences between module systems are eliminated through standardized UMD output, which is conducive to achieving cross-environment compatibility. In some embodiments, the dependency configuration items include external dependency configuration items. The above - mentioned dependency configuration operation, based on the received dependency configuration, configures at least one dependency for each dependency configuration item, and sets the output of each dependency in UMD format to obtain a UMD module corresponding to each dependency, including:

[0171] According to the received external dependency configuration operation, an external dependency is set for the external dependency configuration item, and the output of the external dependency is set to the UMD format to obtain a third-party UMD module corresponding to the third dependency; the external dependency includes a first dependency resource from a third party.

[0172] The above directory structure may include, for example, external dependency configuration items.

[0173] The external dependency configuration operation may be configured to set one or more external dependencies for an external dependency configuration item. The external dependency configuration operation may be performed by presetting a dependency configuration tool to declare external dependencies.

[0174] External dependencies include first dependency resources of a third party. The first dependency resource here can be an executable code library, tool or service provided by a third party. The first dependency resource can be maintained by the third party that provides the first dependency resource.

[0175] Specifically, the external dependency configuration operation can, for example, set the external dependency identifier in the external dependency configuration item, and set all first dependency resources (static resources) that need to be deployed to the production environment for the external dependency. The above-mentioned static resources may, for example, include packaged JavaScript files (such as dependencyName.js) and generated CSS files (such as dependencyName.css), etc.

[0176] In these embodiments, by setting an external dependency for an external dependency configuration item and setting the output of the external dependency in UMD format to obtain a UMD module corresponding to the external dependency, since the external dependency is output in a standardized UMD format, the external dependency can be reused in different scenarios (e.g., internal dependency, page dependency, etc.) without the need for repeated packaging, which can accelerate the packaging process. In addition, by centrally managing third-party dependencies in the external dependency configuration item, repeated installation of different versions of dependencies in multiple modules can be avoided, reducing the risk of dependency conflicts. Since the UMD format supports no framework constraints, the front-end resources generated by the external dependencies output in the UMD format can be used by application development frameworks of different technology stacks.

[0177] In some embodiments, the dependent configuration item includes an internal dependent configuration item, and the method further includes the following steps:

[0178] First, create the first source code for the function shared within the front-end resource.

[0179] Secondly, the preset construction tool is called to construct the first source code into the second dependency resource corresponding to the internal dependency according to the preset format.

[0180] In these embodiments, the internal dependencies in the internal dependency configuration project are functions shared within the front-end resources, such as common functional modules, tool libraries, or internally reused user interface (UI) components shared within the front-end resources.

[0181] In this embodiment, a first source code for a function shared within a front-end resource can be created based on the developer's editing operation. The first source code here can be a source code edited using any code editing tool. The above-mentioned preset construction tool can edit, optimize and package the first source code to obtain a second dependent resource corresponding to the internal dependency.The second dependent resources include but are not limited to: JavaScript files, CSS files, and images, etc. The above-mentioned preset construction tool can be any construction tool that can compile, optimize, and package source code.

[0182] The preset format may be a format that meets the browser requirements or the server-side requirements for the runtime environment. The second dependent resource may be called as an internal dependency within the front-end resource.

[0183] Further, in these embodiments, the above-mentioned operation of configuring at least one dependency for each dependency configuration item according to the received dependency configuration, and setting the output of each dependency in UMD format to obtain a UMD module corresponding to each dependency, includes:

[0184] According to the internal dependency configuration operation, the internal dependency is set for the internal dependency configuration item, and the output of the internal dependency is configured into the UMD format to obtain the internal UMD module corresponding to the internal dependency; wherein the internal dependency includes the corresponding second dependency resource.

[0185] In these implementations, the dependency configuration operation may be an internal dependency configuration operation performed by a developer. The internal dependency configuration operation may configure one or more internal dependencies created by the internal dependency creation step in an internal dependency configuration item, thereby enabling unified management of internal dependencies by the internal dependency configuration item.

[0186] The internal UMD module includes a public library and / or a public UI component; the public library can be a general function, which may include but is not limited to: logging tools, network requests, data storage, data verification, user authentication, data analysis, device information, file operations, encryption / decryption and Web socket communication, etc.

[0187] Common UI components provide reusable interface elements to ensure consistent UI styles across SDKs. Common UI components include, but are not limited to: basic components such as buttons, input boxes, and pop-up windows; data display components such as lists, cards, tables, and charts; and navigation components such as navigation bars and sidebars. In these embodiments, the common functions within the front-end resources, such as various tool functions, etc., are packaged into UMD modules as internal dependencies through the above steps and can be reused in multiple pages or modules to avoid repeated development. In addition, the front-end resources generated by the above-mentioned internal dependencies can also be applied in different environments, thereby facilitating the cross-framework application of front-end resources.

[0189] In some embodiments, the above-mentioned dependency configuration item includes a page dependency configuration item, and the method further includes:

[0190] Creating a second source code corresponding to at least one page of the front-end resource;

[0191] calling a preset construction tool to construct the second source code corresponding to each page into a third dependency resource corresponding to the page dependency according to a preset format; and

[0192] According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to UMD format to obtain a UMD module corresponding to each dependency, including:

[0193] According to the page dependency configuration operation, at least one page dependency is set in the page configuration item; and the output of each page dependency is set to the UMD format to obtain the page UMD module corresponding to each page; wherein, each page dependency includes the corresponding third dependency resource.

[0194] In these embodiments, a second source code corresponding to at least one page can be created according to the user's editing operation. The second source code corresponding to any page can declare the use of the internal dependency configured in the internal dependency configuration item and the external dependency configured in the external dependency configuration item. After creating the second source code corresponding to each page, the preset construction tool is called to compile, optimize, and package the second source code into a third dependent resource suitable for the runtime environment of the browser or server. The preset construction tool can be any construction tool that can compile, optimize, and package the second source code. Each page dependency here corresponds to a third dependent resource.

[0196] The output format of the page dependency can also be set to the UMD format through the construction tool to obtain the page UMD module corresponding to the page dependency.

[0197] In these embodiments, by declaring dependencies on third-party UMD modules and / or internal UMD modules in the page UMD module, the dependencies can be clarified, the functional integrity of the page can be ensured, and it is helpful to load dependencies according to the requirements of the page, reduce the coupling between modules, and provide code maintainability and reusability.

[0198] Each page module of the page dependency configuration item can provide a sample page. When using the above-mentioned cross-framework front-end resources to develop an application, the above-mentioned page module can be called without having to build it from scratch.

[0199] Each page depends on its corresponding UMD module, and they are independent of each other.

[0200] In these embodiments, through the above process, a second source code can be created for each page, and the second source code of each page can be built into an independent UMD module, thereby realizing the dynamic loading of page modules. Only the currently accessed page module and its dependencies need to be loaded, which helps to reduce the amount of resource data loaded. The dependencies of each page module can be isolated through their respective corresponding global variables, which can avoid external dependency conflicts between different versions among multiple pages. The page module in UMD format does not depend on a specific environment, so the front-end resources generated by the page UMD module can be used across development frameworks.

[0201] Please refer to Figure 2. Figure 2 is a flowchart of the method for constructing reusable front-end resources provided by the present disclosure; as shown in Figure 2, in addition to including steps S210 to S204 that are the same as steps S101 to S104 in the embodiment shown in Figure 1, the method further includes the following steps:

[0202] S205: According to the sandbox environment encapsulation instruction, encapsulate an isolation sandbox for the front-end resources. The isolation sandbox is used to avoid dependency conflicts between different front-end resources.

[0203] Through steps S201 to S204, front-end resources that can be dynamically loaded on demand and applied across frameworks can be obtained. However, there may be dependency conflict problems between the above front-end resources and other front-end resources (such as front-end resources of different versions).In order to solve the dependency conflict problem, it is necessary to add an isolation sandbox to the front-end resources obtained in steps S201 to S204.

[0204] The above-mentioned sandbox environment packaging instruction can be issued by the user or automatically issued by the electronic device.

[0205] After receiving the sandbox environment encapsulation instruction, the above-mentioned execution entity can encapsulate the isolated sandbox for the front-end resources obtained by steps S210~S204.

[0206] In this embodiment, by encapsulating instructions according to the sandbox environment and encapsulating an isolated sandbox for reusable front-end resources, potential front-end resource dependency conflicts can be avoided.

[0207] In some optional implementations of this embodiment, the above-mentioned isolation sandbox is an iframe sandbox. The iframe sandbox utilizes the browser's native isolation capability to<iframe> Tags create independent browsing contexts, naturally isolating child pages from their parent pages. Configure permissions through the sandbox attribute to restrict script execution, form submission, and other behaviors on child pages.

[0208] The iframe sandbox provides an independent window object for front-end resources, avoiding global variable naming conflicts with the host page. The iframe sandbox limits the permissions of internal scripts through the sandbox attribute, preventing third-party code in the front-end resources from tampering with the Document Object Model (DOM), small text files (Cookies), or global variables of the host page, thereby reducing the risk of being attacked. The data security of the host page can be improved. In addition, because the iframe sandbox provides an independent operating environment for front-end resources, the iframe sandbox can be used to apply front-end resources to pages developed using different frameworks, which can improve the compatibility of front-end resources. In addition, it can also support the setting of front-end resources developed using different frameworks on the same page.

[0209] In some optional implementations of this embodiment, the above step S205 includes the following sub-steps:

[0210] First, create an independent iframe sandbox environment based on the sandbox environment encapsulation instructions.

[0211] After receiving the instruction to create a sandbox environment for the front-end resources created by steps S201 to S204, the above-mentioned execution entity can create an independent iframe sandbox environment for the front-end resources.

[0212] Second, initialize the srcdoc attribute of the iframe sandbox environment to provide a front-end resource mounting entry. Specifically ,<iframe> The srcdoc attribute of the html document structure is inlined, and the html document structure includes the required meta information and the mount point (that is, the front-end resource mounting entry). The HTML frame defined by the document structure includes:<!DOCTYPE html> 、<html> 、<head> (including character encoding and viewport configuration) and<body> Label.

[0215] Insert a placeholder container (such as ), as the mounting entry for front-end resources.

[0216] Third, load the iframe sandbox environment, and dynamically load the front-end resources after the iframe sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window in the sandbox is returned for calling through the callback function.

[0217] Dynamically create an isolated<iframe> container, and impose security restrictions on the container (sandboxing), and then<iframe> Load and run reusable front-end resource code in the container. This allows for isolated execution of reusable front-end resource code, preventing internal code from being affected or contaminating external pages.

[0218] can be sandboxed<iframe> A global callback function is defined within the container for external calls. Front-end resources are dynamically loaded, and the callback is triggered after loading is complete. External access to the sandbox's window object occurs via postMessage or by directly calling methods within the iframe.

[0219] In these embodiments, upon receiving a sandbox environment encapsulation instruction, an independent iframe sandbox environment is created, and a mounting entry for front-end resources is provided in the iframe sandbox environment. The sandbox environment is loaded and then the front-end resources are loaded. After the front-end resources are loaded successfully, the window in the sandbox is returned through the callback function for calling, thereby achieving the encapsulation of the iframe sandbox environment for the front-end resources.

[0220] In some embodiments, the front-end resource also includes a parameter injection entry, wherein the parameter injection entry is used to receive data to be processed; the data to be processed includes data obtained across domains by an application program within the front-end resource.

[0221] Cross-origin refers to a browser's restriction on web pages initiating network requests from one domain name (or port, protocol) to another domain name for security reasons. Only when the protocol (e.g., Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS)), domain name (example.com), and port (80 / 443) are completely consistent is it considered same-origin; otherwise, it is considered cross-origin. If any one or more of the protocol, domain name, and port number used by the front-end deployment and the back-end API deployment are inconsistent, data retrieval is considered cross-origin.

[0222] Cross-domain data acquisition may result in problems such as the front end being unable to directly access APIs from different sources due to browser security restrictions blocking cross-domain requests.

[0223] The above-mentioned parameter injection entry can be a predefined initial function, object, etc., used to receive data passed in by the application.

[0224] Initial function: such as SDK.init(config), which passes initial configuration (such as user information and permission declaration) through function parameters. Configuration objects: For example , SDK.setup({data:{}}) allows complex parameters to be passed through structured objects. This provides applications with a clear parameter injection entry point, preventing direct manipulation of the SDK's internal logic. It also mandates that parameters conform to the SDK's agreed-upon data structure (e.g., field type, nesting level), reducing integration errors.

[0226] In the above implementation, the front-end resources are stripped of the data interaction part, and the application using the front-end resources can freely choose the background for data interaction. After obtaining the data, it is passed into the above-mentioned front-end application in the form of parameters, thereby avoiding cross-domain problems caused by data interaction.

[0227] Please refer to Figure 3. Figure 3 is a schematic flowchart of the application creation method provided by the present disclosure. As shown in Figure 3, the method includes the following steps:

[0228] S301: Receive a call instruction for front-end resources during the application development process; the parameters indicated by the call instruction include the mounting element, the display style, and the target function to be called.

[0229] Among them, the above front-end resources are created by the reusable front-end resource construction method provided by the embodiment shown in Figure 1.

[0230] In this embodiment, the execution subject of the application creation method can be an electronic device for application developers to develop or maintain applications, including but not limited to terminal devices or servers, etc. An application development tool can run on the above electronic device. Developers can use the application development tool to develop applications. Front-end resources can be referenced during the application development.

[0231] The development tool can reference front-end resources during the application development according to the developer's operations. Specifically, the above front-end resources can be configured into the code of the application.

[0232] The above front-end resources can be resources encapsulated as an SDK. The above call instruction can be issued by the application developer or automatically triggered by the above electronic device according to the preset application development process.

[0233] The above call instruction can include the following parameters: the target function of the front-end resource to be called, the page element for mounting the instance generated by the front-end resource to be called, and the display style of the target function of the front-end resource to be called. The display style includes settings such as width and height.

[0234] The above-mentioned target functions can be tool functions and user interface components that can be provided by external dependencies and internal dependencies of front-end resources, or they can be pages provided by one or more page dependencies.

[0235] S302: Pass the parameters into the front-end resources.

[0236] S303: Receive the access interface of the target function instance returned by the callback function corresponding to the front-end resource.

[0237] The above parameters may be parameters passed into the front-end resource. The above callback function may be registered by the development tool and used for information interaction with the front-end resource. The development tool can pass the above parameters into the front - end resource through the callback function of the front-end resource. After the front-end resource receives the above parameters, it performs an initialization operation. During the initial operation, the global variable agent dynamically loads the dependencies (including one or more of external dependencies, internal dependencies and page dependencies) required for the above target function from the dependency directory according to the target function. A corresponding instance is constructed according to the dependencies required for the target function.

[0239] Target function instances can be used to generate structured data or render a user interface.

[0240] The above development tool can receive an access interface to the target function instance returned by the function.

[0241] S304: Display the running result of the target function instance obtained by accessing the access interface in a display style at the position corresponding to the mounting element; the target function instance is generated by the front-end resource according to the target function.

[0242] The development tool can access the target function instance through the access interface and call the target function. The access result of the target function instance is rendered in the mount element with the display style.

[0243] For example, the target function instance can be a page-level function instance. By calling the above target function instance, the page corresponding to the target page module corresponding to the target function instance is rendered to the mounting element.

[0244] The dependent executable code required to implement the above-mentioned target functional instance can be integrated into the code of the developed application.

[0245] S305: Create an application based on the running results of the target function instance.

[0246] After obtaining the running results of the target function instance (such as structured data and rendered user interface), the running results of the above target function instance can be integrated with other logic to obtain the above application.

[0247] In addition, the user can edit the running results of the above-mentioned target function instance, such as entering text, adjusting the display style, etc.

[0248] In this embodiment, during the application development process, a call instruction for a front-end resource is received, and the parameters indicated by the call instruction are passed into the front-end resource; an access interface of the target function instance returned by the callback function is received, and the operation result obtained by accessing the target function instance through the access interface of the target function instance output by the front-end resource is received, and an application is created based on the above operation result. The above-mentioned front-end resources are reusable across frameworks, and the front-end resources constructed under different frameworks are used to conveniently create an application. In addition, the target function instance is dynamically generated by loading dependencies on demand from the front-end resources, thereby making it possible to lightweight the application.

[0249] In some optional implementations of this embodiment, the front-end resources are front-end resources encapsulated in an isolated sandbox; and step S302 includes:

[0250] The parameters are transmitted to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein the front-end resource running in the isolated sandbox monitors the parameter transmission event and obtains the parameters from the monitored parameter event; and step S303 includes:

[0251] The callback function corresponding to the front-end resource receives the target function instance access interface returned through the preset secure cross-domain communication mechanism.

[0252] In these optional implementations, in order to resolve dependency conflicts between different front-end resources, a sandbox environment can be encapsulated for the front-end resources, and the front-end resources run in an isolated sandbox to achieve isolation between different front-end resources.

[0253] A proxy object can be created in an isolated sandbox, and the proxy object can only contain the method name corresponding to the target function.

[0254] Applications can communicate with the isolated sandbox via a pre-defined secure cross-domain communication mechanism (e.g., postMessage). These applications can send parameters (e.g., mounted elements, display styles, and target functions) to the isolated sandbox via the pre-defined secure cross-domain communication mechanism to ensure cross-domain security. The SDK within the sandbox receives the parameters by listening for message events and processes the messages from the application.

[0255] Front-end resources in the isolated sandbox can be initialized to generate target function instances according to the target function. After the target function instance in the isolated sandbox is initialized, the access interface of the target function instance is passed back to the application through a preset secure cross-domain communication mechanism. The access interface includes methods corresponding to the restricted target function (such as startDesign, getSchema), rather than directly exposing the target function instance. The above application receives the access interface sent by the isolated sandbox through a message event. All subsequent method calls send instructions through a preset secure cross-domain communication mechanism, and the sandbox returns a serialized result through the preset secure cross-domain communication mechanism after execution.

[0256] An example will be given below for low-code design. Please refer to Figure 4, Figure 4 is a schematic diagram of an application scenario. The front-end resources are encapsulated in the isolated sandbox. As shown in Figure 4, in the application development tool, the front-end resources 41 with an isolated sandbox are referenced; the application development tool can call the front-end application initialization method (such as init()) according to the user's call instruction and pass in the parameters 42 indicated by the call instruction. The parameters indicated by the call instruction include the mounting element, display style, and the target function to be called. A callback function (such as onSuccess) 43 is passed in during initialization to receive the initialization status or error information of the SDK. The front-end resources perform initialization operations according to the init() method and enter the callback function for function calls of the front-end resources after successful initialization 44: create an iframe isolated sandbox, inject the basic HTML structure (including the mounting point) through srcdoc, dynamically load the UMD module corresponding to the target function in the iframe, and generate a template function instance; establish a preset secure cross-domain communication mechanism channel for subsequent interaction between the development tool and the front-end resources. The callback function ensures that the operation is not executed until the target function instance is ready, avoiding race conditions. At this time, the running result of the target function instance is integrated into the system page. Call start design (startDesgin) for low-code design 45, and the running result of the target function instance is rendered at the mounting element.The running result of the target function instance can provide a low-code editing interface. The user can design a page by dragging components in the low-code editing interface. Obtain the page JSON structure 46 designed in the low-code editing interface currently. The target function instance can return the page JSON structure (such as component tree, configuration) designed in the low-code editing interface. The application development tool receives the page JSON structure through a callback and stores it in the background database: persist the design result; it can also be rendered and previewed on the application development tool page.

[0257] In these implementation manners, for the front-end resources encapsulated in the sandbox environment, a preset secure cross-domain communication mechanism is used for communication between the front-end resources and the application, and between the target function instances provided by the front-end resources, so as to implement the encapsulation and invocation of the front-end resources through the sandbox isolation and the secure cross-domain communication mechanism, and realize the flexible reuse and efficient integration of the front-end resource module while ensuring security.

[0258] Figure 5 is a schematic structural diagram of the reusable front-end resource construction device provided by this application. As shown in Figure 5, the reusable front-end resource construction device 50 provided in this embodiment includes:

[0259] The first receiving module 501 is used to obtain the dependency directory configured in the single-repository multi-module architecture; among them, the dependency directory includes multiple UMD modules;

[0260] The first obtaining module 502 is used to obtain the mapping relationship between the relative paths and global variables of each UMD module;

[0261] The first loading module 503 is used to dynamically load the UMD module to be called by the front-end resources according to the construction instruction of the reusable front-end resources and using the global variable proxy according to the mapping relationship;

[0262] The first generating module 504 is used to generate front-end resources based on the loaded multiple UMD modules.

[0263] In a possible implementation, the first loading module 503 is specifically used to: For any call request to any UMD module to be called, the global variable proxy is called to intercept the call request;

[0265] Using the global variable proxy to traverse the global variables exposed by the loaded UMD module, and determining whether the UMD module to be called has been loaded based on the traversal results;

[0266] In response to determining that the UMD module to be called is not loaded, the absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path.

[0267] In one possible implementation, the device further includes a dependency configuration module (not shown in the figure), which determines the dependency directory configured in the single warehouse multi-module architecture based on the following steps:

[0268] creating dependent configuration items according to preset operations, wherein the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items, and page dependent configuration items;

[0269] According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to the UMD format to obtain the UMD module corresponding to each dependency.

[0270] In one possible implementation, the dependent configuration item includes an external dependent configuration item; The dependency configuration module is specifically used for:

[0272] According to the received external dependency configuration operation, configure the external dependency for the external dependency configuration item, and set the output of the external dependency to the UMD format to obtain a third-party UMD module corresponding to the external dependency; the external dependency includes a first dependency resource from a third party.

[0273] In one possible implementation, the dependency configuration item includes an internal dependency configuration item, and the device further includes an internal dependency construction module (not shown in the figure), and the internal dependency construction module is used to:

[0274] creating a first source code for a function shared within the front-end resource;

[0275] Calling a preset construction tool to construct the first source code into a second dependency resource corresponding to the internal dependency according to a preset format; and the dependency configuration module is specifically used to:

[0276] According to the received internal dependency configuration operation, internal dependencies are configured for the internal dependency configuration item, and the output of the internal dependency is configured into the UMD format to obtain an internal UMD module corresponding to the internal dependency; wherein the internal dependency includes the corresponding second dependency resource.

[0277] In one possible implementation, the dependency configuration item includes a page dependency configuration item, and the device further includes a page dependency construction module (not shown in the figure), which is used to:

[0278] Creating a second source code corresponding to at least one page of the front-end resource;

[0279] Call the preset construction tool to construct the second source code corresponding to each page into the third dependency resource corresponding to the page dependency according to the preset format; and the dependency configuration module is specifically used to: set at least one page dependency in the page configuration item according to the received page dependency configuration operation; and set the output of each page dependency to UMD format to obtain the page UMD module corresponding to each page; wherein, each page dependency includes the corresponding third dependency resource.

[0280] In one possible implementation, the device further includes a sandbox encapsulation module (not shown in the figure), which is configured to:

[0281] According to the sandbox environment packaging instructions, an isolated sandbox is encapsulated for the front-end resources. The isolated sandbox is used to avoid dependency conflicts between different front-end resources.

[0282] In a possible implementation, the sandbox encapsulation module is specifically configured to:

[0283] Create an independent sandbox environment according to the sandbox environment encapsulation instruction;

[0284] Initialize the srcdoc attribute of the sandbox environment to provide a mounting entry for the front-end resources;

[0285] Load the sandbox environment, and dynamically load the front-end resources after the sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window within the sandbox is returned through a callback function for invocation.

[0286] In a possible implementation, the front-end resources further include a parameter injection entry, where the parameter injection entry is used to receive the data to be processed to be processed by the front-end resources; the data to be processed includes the data obtained by the application program across domains within the front-end resources.

[0287] In a possible implementation, the front-end resources are resources encapsulated as an SDK.

[0288] The reusable front-end resource construction device provided in this embodiment can execute the methods provided in the method embodiments shown in FIGS. 1 and 2 above. The implementation principles and technical effects are similar, and will not be elaborated here in this embodiment.

[0289] Figure 6 is a schematic structural diagram of an application creation device provided by the present application. As shown in Figure 6, the application creation device 60 provided in this embodiment includes:

[0290] A second receiving module 601, configured to receive a call instruction for front-end resources during the application development process; the parameters indicated by the call instruction include a mounting element, a display style, and a target function to be called; wherein, the front-end resources are created by a reusable front-end resource construction device shown in Figure 5;

[0291] A parameter transmission module 602, configured to pass the parameters into the front-end resources;

[0292] A third receiving module 603, configured to receive an access interface of a target function instance returned by a callback function corresponding to the front-end resources;

[0293] A display module 604, configured to display the operation result of the target function instance accessed through the access interface in the position corresponding to the mounting element in the display style; the target function instance is generated by the front-end resources according to the target function;

[0294] An application creation module 605, configured to create an application program based on the operation result of the target function instance.

[0295] In a possible implementation manner, the front-end resources are front-end resources encapsulated in an isolated sandbox; and the parameter transmission module 602 is specifically configured to:

[0296] Transmit the parameters to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein, the front-end resources running in the isolated sandbox listen for parameter transmission events and obtain the parameters from the monitored parameter events; and the second receiving module 603 is specifically configured to:

[0297] Receive the access interface of the target function instance returned by the callback function corresponding to the front-end resources through a preset secure cross-domain communication mechanism.

[0298] The application creation device provided in this embodiment can execute the method provided in the method embodiment shown in Figure 3 above. Its implementation principle and technical effects are similar, and will not be elaborated here in this embodiment.

[0299] Figure 7 is a schematic structural diagram of an electronic device provided in this application. As shown in Figure 7, the electronic device 70 provided in this embodiment includes: at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. Among them, the processor 701, the memory 702, and the communication component 703 are connected through a bus.

[0300] In the specific implementation process, at least one processor 701 executes the computer execution instructions stored in the memory 702, so that at least one processor 701 executes the above method.

[0301] The specific implementation process of the processor 701 can be referred to the above method embodiment. Its implementation principle and technical effects are similar, and will not be elaborated here in this embodiment.

[0302] In the above embodiments, it should be understood that the processor can be a central processing unit (English: Central Processing Unit, abbreviated: CPU), or other general-purpose processors, digital signal processors (English: Digital Signal Processor, abbreviated: DSP), application specific integrated circuits (English: Application Specific Integrated Circuit, abbreviated: ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in combination with the invention can be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

[0303] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[0304] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. A bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the drawings of this application are not limited to only one bus or one type of bus.

[0305] The present application also provides a computer program product, comprising a computer program, which implements the above method when executed by a processor.

[0306] The present application also provides a computer-readable storage medium, which stores computer-executable instructions. When the processor executes the computer-executable instructions, the above method is implemented.

[0307] The readable storage medium may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0308] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also be present in a device as discrete components.

[0309] The division of units is merely a logical functional division. In actual implementation, other division methods may be used. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, which may be electrical, mechanical or other forms.

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

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

[0312] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0313] It will be understood by those skilled in the art that all or part of the steps of implementing the above-mentioned various method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned various method embodiments are executed; and the aforementioned storage medium includes various media that can store program codes, such as ROM, RAM, magnetic disk or optical disk.

[0314] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein.The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and variations may be made without departing from the scope of the present invention. The scope of the present invention is limited only by the appended claims.< / iframe>

Claims

1. A reusable front-end resource construction method, characterized in that: include: Obtain a dependency directory configured in a single-repository multi-module architecture; wherein the dependency directory includes multiple UMD modules; Obtaining the mapping relationship between the relative path of each UMD module and the global variable; According to the construction instructions of the reusable front-end resources, the UMD module to be called by the front-end resources is dynamically loaded using the global variable proxy according to the mapping relationship; The front-end resources are generated based on the loaded multiple UMD modules.

2. The method according to claim 1, characterized in that The method of dynamically loading the UMD module to be called by the front-end resource according to the construction instruction of the reusable front-end resource and the mapping relationship by using the global variable proxy includes: For any call request to a UMD module to be called, call the global variable proxy to intercept the call request; Utilize the global variable proxy to traverse the global variables exposed by the loaded UMD module, and determine whether the UMD module to be called has been loaded according to the traversal result; In response to determining that the UMD module to be called is not loaded, an absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path.

3. The method according to claim 1, characterized in that The dependency directory configured in the single-repository multi-module architecture is obtained based on the following steps: Create dependent configuration items according to preset operations, where the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items, and page dependent configuration items; According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to a UMD format to obtain a UMD module corresponding to each dependency.

4. The method according to claim 3, characterized in that The dependent configuration items include external dependent configuration items; The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes: According to the received external dependency configuration operation, an external dependency is configured for the external dependency configuration item, and the output of the external dependency is set to UMD format to obtain a third-party UMD module corresponding to the external dependency; the external dependency includes a first dependency resource from a third party.

5. The method according to claim 3, characterized in that The dependent configuration item includes an internal dependent configuration item, and the method further includes: Creating a first source code for a function shared within the front-end resource; Invoking a preset construction tool to construct the first source code into a second dependency resource corresponding to the internal dependency according to a preset format; and The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes: According to the received internal dependency configuration operation, an internal dependency is configured for the internal dependency configuration item, and the output of the internal dependency is configured in a UMD format to obtain an internal UMD module corresponding to the internal dependency; wherein the internal dependency includes a corresponding second dependency resource.

6. The method according to claim 3, characterized in that The dependency configuration item includes a page dependency configuration item, and the method further includes: Creating a second source code corresponding to at least one page of the front-end resource; Invoking a preset construction tool to construct the second source code corresponding to each of the pages into a third dependency resource corresponding to the page dependency according to a preset format; and The step of configuring at least one dependency for each dependency configuration item according to the received dependency configuration operation, and setting the output of each dependency to a UMD format to obtain a UMD module corresponding to each dependency, includes: According to the received page dependency configuration operation, at least one page dependency is set in the page configuration item; and the output of each page dependency is set to UMD format to obtain a page UMD module corresponding to each page; wherein each page dependency includes a corresponding third dependency resource.

7. The method according to any one of claims 1 to 6, characterized in that Also includes: According to the sandbox environment packaging instruction, an isolated sandbox is packaged for the front-end resources, and the isolated sandbox is used to avoid dependency conflicts between different front-end resources.

8. The method according to claim 7, characterized in that The step of encapsulating an isolated sandbox for the front-end resources according to the sandbox environment encapsulation instruction includes: Creating an independent sandbox environment according to the sandbox environment packaging instructions; Initialize the srcdoc attribute of the sandbox environment and provide a mounting entry for the front-end resources; Loading a sandbox environment, and dynamically loading the front-end resources after the sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window in the sandbox is returned for calling through a callback function.

9. The method according to any one of claims 1 to 6, characterized in that The front-end resource further includes a parameter injection entry, wherein the parameter injection entry is used to receive data to be processed by the front-end resource; the data to be processed includes data obtained across domains by an application program within which the front-end resource is applied.

10. The method according to any one of claims 1 to 6, characterized in that The front-end resources are resources packaged as SDK.

11. A method for creating an application, characterized in that: include: Receiving a call instruction for a front-end resource during application development; the parameters indicated by the call instruction include a mounting element, a display style, and a target function to be called; wherein the front-end resource is created by the method according to any one of claims 1 to 10; Passing the parameters into the front-end resource; Receive an access interface for the target function instance returned by the callback function corresponding to the front-end resource; Displaying the running result of the target function instance obtained by accessing the access interface in the display style at the position corresponding to the mounting element; the target function instance is generated by the front-end resource according to the target function; The application is created based on the running result of the target function instance.

12. The method according to claim 11, characterized in that The front-end resources are front-end resources encapsulated in an isolated sandbox; And the step of transferring the parameters to the front-end resource includes: The parameters are transmitted to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein the front-end resource running in the isolated sandbox monitors parameter transmission events and obtains the parameters from the monitored parameter events; and the access interface for receiving the target function instance returned by the callback function corresponding to the front-end resource includes: Receive the target function instance access interface returned by the callback function corresponding to the front-end resource through the preset secure cross-domain communication mechanism.

13. A reusable front-end resource construction device, characterized in that: include: A first receiving module is configured to obtain a dependency directory configured in a single-repository multi-module architecture; wherein the dependency directory includes multiple UMD modules; A first acquisition module is used to obtain a mapping relationship between the relative path of each UMD module and the global variable; A first loading module is used to dynamically load the UMD module to be called by the front-end resource according to the construction instruction of the reusable front-end resource and the mapping relationship using a global variable proxy; The first generating module is used to generate the front-end resources based on the loaded multiple UMD modules.

14. The device according to claim 13, characterized in that The first loading module is specifically used for: For any call request to a UMD module to be called, call the global variable proxy to intercept the call request; Utilize the global variable proxy to traverse the global variables exposed by the loaded UMD module, and determine whether the UMD module to be called has been loaded according to the traversal result; In response to determining that the UMD module to be called is not loaded, an absolute path of the UMD module to be called is determined based on the relative path of the UMD module to be called, and the UMD module to be called is loaded according to the absolute path.

15. The device according to claim 13, characterized in that The apparatus further includes a dependency configuration module, which determines a dependency directory configured in the single-warehouse multi-module architecture based on the following steps: Create dependent configuration items according to preset operations, where the dependent configuration items include one or more of external dependent configuration items, internal dependent configuration items, and page dependent configuration items; According to the received dependency configuration operation, at least one dependency is configured for each dependency configuration item, and the output of each dependency is set to a UMD format to obtain a UMD module corresponding to each dependency.

16. The device according to claim 15, characterized in that The dependent configuration items include external dependent configuration items; The dependency configuration module is specifically used for: According to the received external dependency configuration operation, an external dependency is configured for the external dependency configuration item, and the output of the external dependency is set to UMD format to obtain a third-party UMD module corresponding to the external dependency; the external dependency includes a first dependency resource from a third party.

17. The device according to claim 15, characterized in that The dependency configuration item includes an internal dependency configuration item, and the device further includes an internal dependency construction module, wherein the internal dependency construction module is used to: Creating a first source code for a function shared within the front-end resource; Invoking a preset construction tool to construct the first source code into a second dependency resource corresponding to the internal dependency according to a preset format; and The dependency configuration module is specifically used for: According to the received internal dependency configuration operation, an internal dependency is configured for the internal dependency configuration item, and the output of the internal dependency is configured in a UMD format to obtain an internal UMD module corresponding to the internal dependency; wherein the internal dependency includes a corresponding second dependency resource.

18. The device according to claim 15, characterized in that The dependency configuration item includes a page dependency configuration item, and the device further includes a page dependency construction module, wherein the page dependency construction module is used to: Creating a second source code corresponding to at least one page of the front-end resource; Invoke a preset construction tool to construct the second source code corresponding to each of the pages into a third dependency resource corresponding to the page dependency according to a preset format; as well as The dependency configuration module is specifically used to: set at least one page dependency in the page configuration item according to the received page dependency configuration operation; and set the output of each page dependency to UMD format to obtain a page UMD module corresponding to each page; wherein each page dependency includes a corresponding third dependency resource.

19. The device according to any one of claims 13 to 18, characterized in that The device further includes a sandbox encapsulation module, wherein the sandbox encapsulation module is configured to: According to the sandbox environment packaging instruction, an isolated sandbox is packaged for the front-end resources, and the isolated sandbox is used to avoid dependency conflicts between different front-end resources.

20. The device according to claim 19, characterized in that The sandbox encapsulation module is specifically used to: Creating an independent sandbox environment according to the sandbox environment packaging instructions; Initialize the srcdoc attribute of the sandbox environment and provide a mounting entry for the front-end resources; Loading a sandbox environment, and dynamically loading the front-end resources after the sandbox environment is successfully loaded; wherein, after the front-end resources are successfully loaded, the window in the sandbox is returned for calling through a callback function.

21. The device according to any one of claims 13 to 18, characterized in that The front-end resource also includes a parameter injection entry, wherein the parameter injection entry is used to receive data to be processed by the front-end resource; the data to be processed includes data obtained across domains by the main application within which the front-end resource is applied.

22. The device according to any one of claims 13 to 18, characterized in that The front-end resources are resources packaged as SDK.

23. An application creation device, characterized in that: include: A second receiving module is configured to receive a call instruction for a front-end resource during application development; the call instruction indicates parameters including a mount element, a display style, and a target function to be called; wherein the front-end resource is created by the apparatus according to any one of claims 13 to 22; A parameter transmission module, used to transfer the parameters to the front-end resources; A third receiving module is used to receive an access interface of a target function instance returned by a callback function corresponding to the front-end resource; A display module is configured to display the running result of the target function instance obtained by accessing the access interface in the display style at the position corresponding to the mounting element; the target function instance is generated by the front-end resource according to the target function; An application creation module is used to create the application program based on the running result of the target function instance.

24. The device according to claim 23, characterized in that The front-end resources are front-end resources encapsulated in an isolated sandbox; and the parameter transmission module is specifically used to: The parameters are transmitted to the isolated sandbox through a preset secure cross-domain communication mechanism; wherein the front-end resources running in the isolated sandbox monitor parameter transmission events and obtain the parameters from the monitored parameter events; and the second receiving module is specifically configured to: Receive the target function instance access interface returned by the callback function corresponding to the front-end resource through the preset secure cross-domain communication mechanism.

25. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor executes the reusable front-end resource construction method as described in any one of claims 1-10, or the application creation method as described in any one of claims 11-12.

26. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the reusable front-end resource construction method described in any one of claims 1-10, or the application creation method described in any one of claims 11-12.

27. A computer program product, comprising a computer program, which, when executed by a processor, implements the reusable front-end resource construction method described in any one of claims 1 to 10, or the application creation method described in any one of claims 11 to 12.

Images