Data processing methods, devices, equipment, and storage media based on micro-frontends

Abstract

This disclosure relates to a data processing method, apparatus, device, and storage medium based on a micro-frontend. The method involves obtaining source code files for at least one sub-application used to construct the micro-frontend; the at least one sub-application includes multiple page modules; a packaging module is invoked to package the source code files of the at least one sub-application to obtain a script file; the script file includes rendered text exposed by the multiple page modules, processed by a target plugin, which is integrated into the packaging module; the script file is stored in a target storage location so that during the loading of the sub-application, the exposed rendered text is retrieved from the target storage location for rendering. This eliminates the need for separate micro-frontend deployments, simplifying the micro-frontend application process.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a data processing method, apparatus, device and storage medium based on a micro-frontend. Background Technology

[0002] Micro-frontends, as a technology and strategy for collaboratively building web applications by independently deploying features across teams, allow multiple small applications to be combined into a single complete application. Compared to a single frontend repository, micro-frontends favor a smaller and more flexible repository management approach.

[0003] In related technologies, the current construction modes of micro frontends mainly include the isolation mode based on iframe (an HTML tag) and the framework mode based on qiankun (a micro frontend framework). However, the micro frontends built by these methods require multiple micro frontend methods to process each application, making the micro frontend application process relatively complex. Summary of the Invention

[0004] This disclosure provides a data processing method, apparatus, device, and storage medium based on a micro-frontend, to at least solve at least one problem in the related technologies. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a data processing method based on a micro-frontend is provided, comprising:

[0006] Obtain the source code files of at least one sub-application;

[0007] The packaging module is invoked to package the source code files of at least one of the sub-applications to obtain a script file; the script file includes rendered text corresponding to the source code file processed by the target plugin, which is exposed to the outside world; the target plugin is integrated into the packaging module.

[0008] In response to a loading instruction for a target application in at least one of the sub-applications, the target rendering text corresponding to the target application is obtained from the script file, the target rendering text being the rendering text currently loaded by the target application.

[0009] In an alternative implementation, the method further includes:

[0010] In response to a load instruction for a target sub-application in at least one of the sub-applications, the script file and corresponding associated resource data of the target sub-application are obtained from the target storage location;

[0011] Obtain the rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; the target page module includes at least one of the page modules.

[0012] Load the target rendered text and corresponding associated resource data in the main application.

[0013] In an optional implementation, loading the target rendered text and corresponding associated resource data in the main application includes:

[0014] If the loading instruction indicates a non-modular loading mode, the dynamic loading method is invoked to dynamically load the target rendered text and its corresponding associated resource data; or,

[0015] When the loading instruction indicates a modular loading mode, the native loading method is invoked to load the target rendered text and the corresponding associated resource data.

[0016] In one optional implementation, the step of calling the packaging module to package at least one of the source code files of the sub-application to obtain a script file includes:

[0017] The packaging module is invoked to package the source code files of at least one of the sub-applications.

[0018] During the packaging process, the target plugin is invoked to encapsulate the rendering text corresponding to at least one source code file of the sub-application into a rendering function, which is used to expose the rendering text to the outside world.

[0019] Based on the packaged source code file and the rendering function, the script file is obtained.

[0020] In an alternative implementation, the method further includes:

[0021] During the packaging process, the target plugin is invoked to upload the associated resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

[0022] In an optional implementation, the step of invoking the target plugin to upload the associated resource data corresponding to at least one of the sub-application's source code files to the target storage location corresponding to the target storage address includes:

[0023] Invoke the target plugin to point the global resource path corresponding to at least one of the source code files of the sub-application to the target storage address;

[0024] Obtain the associated resource data corresponding to the source code files of at least one of the sub-applications, and upload the associated resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

[0025] In one alternative implementation, the associated resource data includes dependency resource data for characterizing the dependencies between modules or components, or includes static resource data for characterizing that does not need to be changed at runtime, and external resource data for characterizing other associated data that is not packaged.

[0026] In an optional implementation, when the associated resource data includes dependent resource data, the step of obtaining the associated resource data corresponding to at least one source code file of the sub-application and uploading the associated resource data corresponding to the source code file of at least one sub-application to the storage location corresponding to the target storage address includes:

[0027] Obtain the dependency resource data corresponding to at least one of the source code files of the sub-application;

[0028] Upload the dependency resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

[0029] In an optional implementation, when the associated resource data includes static resource data and external resource data, the step of obtaining the associated resource data corresponding to at least one source code file of the sub-application and uploading the associated resource data corresponding to the source code file of at least one sub-application to the storage location corresponding to the target storage address includes:

[0030] Obtain static resource data corresponding to the source code files of at least one of the sub-applications, and upload the static resource data corresponding to the source code files of at least one of the sub-applications to the target storage location corresponding to the target storage address;

[0031] Obtain external resource data corresponding to at least one source code file of the sub-application, and upload the external resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address.

[0032] According to a second aspect of the present disclosure, a data processing apparatus based on a micro-frontend is provided, comprising:

[0033] The first acquisition module is configured to acquire source code files for building at least one sub-application of the micro-frontend; the at least one sub-application includes multiple page modules;

[0034] The first processing module is configured to execute a call to the packaging module to package at least one of the source code files of the sub-application to obtain a script file; the script file exposes rendered text processed by the target plugin to the outside world by multiple page modules, and the target plugin is integrated into the packaging module;

[0035] The storage module is configured to store the script file to a target storage location so that, during the loading of the sub-application, the externally exposed rendering text can be retrieved from the target storage location for rendering.

[0036] In an alternative embodiment, the apparatus further includes:

[0037] The resource acquisition module is configured to execute a loading instruction for a target sub-application in at least one of the sub-applications, and acquire the script file and corresponding associated resource data of the target sub-application from the target storage location.

[0038] The second processing module is configured to execute a rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; the target page module includes at least one of the page modules.

[0039] The loading module is configured to load the target rendered text and corresponding associated resource data in the main application.

[0040] In one alternative implementation, the loading module is specifically configured to execute:

[0041] If the loading instruction indicates a non-modular loading mode, the dynamic loading method is invoked to dynamically load the target rendered text and its corresponding associated resource data; or

[0042] When the loading instruction indicates a modular loading mode, the native loading method is invoked to load the target rendered text and the corresponding associated resource data.

[0043] In an optional implementation, the first processing module includes:

[0044] The packaging submodule is configured to execute the packaging module to package the source code files of at least one of the sub-applications;

[0045] The first processing submodule is configured to call the target plugin during the packaging process to encapsulate the rendering text corresponding to at least one source code file of the sub-application into a rendering function, wherein the rendering function is used to expose the rendering text to the outside.

[0046] The second processing submodule is configured to execute a script file based on the packaged source code file and the rendering function.

[0047] In an alternative embodiment, the apparatus further includes:

[0048] The resource upload module is configured to, during the packaging process, call the target plugin to upload the associated resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address.

[0049] In one optional implementation, the resource upload module includes:

[0050] The address points to a submodule, which is configured to execute a call to the target plugin, pointing the global resource path corresponding to at least one source code file of the sub-application to the target storage address;

[0051] The upload submodule is configured to retrieve the associated resource data corresponding to the source code files of at least one of the sub-applications, and upload the associated resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

[0052] In one alternative implementation, the associated resource data includes dependency resource data for characterizing the dependencies between modules or components, or includes static resource data for characterizing that does not need to be changed at runtime, and external resource data for characterizing other associated data that is not packaged.

[0053] In an optional implementation, where the associated resource data includes dependent resource data, the upload submodule is specifically configured to execute:

[0054] Obtain the dependency resource data corresponding to at least one of the source code files of the sub-application;

[0055] Upload the dependency resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

[0056] In an optional implementation, where the associated resource data includes static resource data and external resource data, the upload submodule is specifically configured to execute:

[0057] Obtain static resource data corresponding to at least one source code file of the sub-application, and upload the static resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address;

[0058] Obtain external resource data corresponding to at least one source code file of the sub-application, and upload the external resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address.

[0059] According to a third aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the micro-frontend-based data processing method as described in any of the above embodiments.

[0060] According to a fourth aspect of the present disclosure, an electronic device is provided, comprising:

[0061] processor;

[0062] Memory used to store the processor's executable instructions;

[0063] The processor is configured to execute the instructions to implement the micro-frontend-based data processing method as described in any of the above embodiments.

[0064] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the micro-frontend-based data processing method provided in any of the above embodiments.

[0065] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects:

[0066] This embodiment of the disclosure obtains source code files for at least one sub-application used to build a micro-frontend; the at least one sub-application includes multiple page modules; a packaging module is invoked to package the source code files of the at least one sub-application to obtain a script file; the script file includes rendered text exposed by the multiple page modules and processed by a target plugin, the target plugin being integrated into the packaging module; the script file is stored in a target storage location so that during the loading of the sub-application, the exposed rendered text is retrieved from the target storage location for rendering. Thus, by invoking a packaging module integrated with a target plugin to package the source code files of at least one sub-application, the target plugin processes multiple page modules to obtain the rendered text exposed for loading the sub-application. Before packaging, there is no need to prepare multiple micro-frontend methods to process each application, and by uniformly uploading the packaged resources to the target storage location, there is no need for each micro-frontend to be published separately beforehand, simplifying the micro-frontend application process and improving the universality of micro-frontend applications.

[0067] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this disclosure, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0069] Figure 1 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0070] Figure 2 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0071] Figure 3 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0072] Figure 4 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0073] Figure 5 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0074] Figure 6 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment.

[0075] Figure 7 This is a block diagram of a micro-frontend-based data processing device according to an exemplary embodiment.

[0076] Figure 8 This is a block diagram illustrating an electronic device for micro-frontend-based data processing according to an exemplary embodiment. Detailed Implementation

[0077] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0078] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0079] Figure 1 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment. Figure 6 This is a flowchart illustrating a micro-frontend-based data processing method according to an exemplary embodiment. Figure 1 and Figure 6 As shown, the micro-frontend-based data processing method can be executed by a micro-frontend-based data processing device. This device can be integrated into a terminal or server device in hardware or software form. It can be implemented by the server or terminal alone, or by the terminal and server working together. The terminal can be, but is not limited to, physical devices such as smartphones, tablets, laptops, desktop computers, smart speakers, smart wearable devices, digital assistants, augmented reality devices, and virtual reality devices, and can also include software such as applications running on the physical device. The server can be, but is not limited to, a standalone server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms. Taking the server as the executing entity, the method includes the following steps:

[0080] In step S101, source code files for at least one sub-application used to build the micro-frontend are obtained; the at least one sub-application includes multiple page modules.

[0081] The source code files can be the code files obtained from developing sub-applications based on a micro-frontend framework. This frontend framework can be Vue, Angular, React, etc. Taking sub-application A as an example, which is developed using the Vue framework, during the micro-frontend development phase, the source code of sub-application A typically exists as a .vue file; this .vue file is the source code file of sub-application A.

[0082] In step S103, the packaging module is invoked to package the source code files of at least one of the sub-applications to obtain a script file; the script file includes multiple page modules that expose rendered text processed by the target plugin, and the target plugin is integrated into the packaging module.

[0083] Since browsers cannot directly run the source code files of individual sub-applications, they typically need to be converted to a browser-supported file format before they can run. During this conversion process, the source code files of each sub-application are usually packaged to obtain a script file that the browser can run. For example, this script file could be a JS file, an MJS file, etc.

[0084] Optionally, a packaging module is invoked to package the source code files of at least one of the sub-applications to obtain script files. This packaging module can be based on Webpack, Rollup, or similar tools. Unlike traditional Webpack and Rollup packaging tools, this module, in addition to possessing the basic packaging functions of Webpack and Rollup, integrates a target plugin for exposing rendered text. The rendered text represents the code segment content corresponding to the rendering code used to perform rendering processing. By exposing the rendered text in the source code files of each sub-application through this target plugin, the script file exposes the rendered text corresponding to the source code file obtained through the target plugin's processing; that is, the script file exposes the rendering code corresponding to the source code file obtained through the target plugin's processing.

[0085] The packaging process differs depending on the packaging tool used. Each packaging tool employs its own packaging steps to process the source code files of each sub-application, resulting in the corresponding script files.

[0086] In an optional implementation, when the packaging module is implemented based on the Rollup packaging tool, the step of calling the packaging module to package the source code files of at least one of the sub-applications to obtain a script file includes:

[0087] The packaging module is invoked to package at least one of the source code files of the sub-application.

[0088] During the packaging process, the target plugin is called to directly expose the rendering function, which is used to point to the rendering text corresponding to at least one of the source code files of the sub-application;

[0089] Based on the packaged source code file and the rendering function, the script file is obtained.

[0090] For example, taking the Rollup packaging tool as an example, its main processes include: [Pre-configuration], [Before Packaging], [Loading Resources], [Module Parsing], [Packaging End], [Rendering Begins], [Rendering Block-Level], [Generating Result Code], [Writing Result Code], [Entry File Conversion], and [Writing End].

[0091] Optionally, the target plugin integrated into the Rollup packaging module is invoked, and the source code files of at least one sub-application are packaged based on the packaging steps corresponding to the Rollup packaging module. In the Rollup packaging process, for example, at the render chunk level, the rendering function's corresponding rendering method can be directly exposed to the outside world. This rendering function points to the rendering text corresponding to the source code file of at least one sub-application, thus exposing the corresponding rendering text externally. Next, the packaged source code files and the code segment corresponding to the rendering function are combined to obtain a script file.

[0092] For example, in the renderChunk step, we can first determine whether the current compiled file is the entry file for the resource by using the input parameter isEntry. If it is, we call the entry.forEach method to iterate through and read the current compiled file. Then, using the export method (other than export default, which exposes the default external code) to export the code corresponding to the rendering function, we append the code to the end of the packaged source code file to obtain the script file.

[0093] In another alternative implementation, such as Figure 2 As shown, when the packaging module is implemented based on the Webpack packaging tool, the step of calling the packaging module to package at least one of the source code files of the sub-application to obtain script files includes:

[0094] In step S201, the packaging module is invoked to package the source code files of at least one of the sub-applications.

[0095] Optionally, the target plugin integrated in the Webpack bundling module is invoked, and the source code files of each sub-application are bundled based on the bundling steps corresponding to the Webpack bundling module to obtain the corresponding script files.

[0096] For example, taking the Webpack bundling tool as an example, its main process includes: [Environment Configuration], [Initialization], [Before Running], [Before Compiling], [In Compiling], [After Compiling], [Before Pushing], [After Pushing], [Bundling Completed].

[0097] In step S203, during the packaging process, the target plugin is invoked to encapsulate the rendering text corresponding to at least one source code file of the sub-application into a rendering function, which is used to expose the rendering text to the outside world.

[0098] Optionally, the packaging module is invoked to package the parsed data of at least one of the sub-application's source code files. During the packaging process, a target plugin integrated into the packaging module is invoked to encapsulate the obtained rendering text corresponding to the source code files of at least one of the sub-applications into a rendering function. This rendering function exposes the rendering text externally, thereby exposing the rendering text corresponding to the source code files of at least one sub-application. Then, based on the packaged source code files and the rendering function, a script file is obtained. This script file exposes the rendering text corresponding to the source code files obtained through the target plugin's processing. The target plugin intervenes in certain stages of the packaging process to assist in micro-frontend integration.

[0099] In an alternative implementation, such as Figure 3 As shown, the rendering text corresponding to at least one source code file of the sub-application that is exposed to the outside world by calling the target plugin includes:

[0100] In step S301, the rendered text corresponding to the source code file of at least one of the sub-applications is obtained.

[0101] Optionally, rendering text can be collected during the Webpack bundling process, such as in the 'exportWebpackCachToGlobal' stage of compilation. For example, in the interopCompilation stage, the exportWebpackCachToGlobal stage can be registered in a hook function of the compilation process using the compiler.hooks.compilation method. This stage can obtain the main template information, and then register the bindGlobalVar stage in the main template's hook function. This stage primarily identifies the rendering code in the manifest file and then uses the text content of the identified rendering code as the rendering text, concatenating it as a string into the output template.

[0102] In step S303, the acquired rendering text is encapsulated into a rendering function for external exposure.

[0103] Optionally, in the Webpack bundling process, at a stage such as 'getting the entry file' (genEntryFile) after bundling, the obtained rendering text can be encapsulated into a callable rendering function, which is then exposed to the outside. For example, in the genEntryFile stage, the core libraries of the micro-frontend application can be retrieved from the global environment ($window) using a pre-registered key (MAI N_KEY). The resource files required by the micro-frontend application can be loaded in batches by calling the load batch files (nameSpace.loadBatchFiles) method, and then encapsulated with the rendering text into a callable rendering function, which is then exposed to the outside.

[0104] During the encapsulation process, only the code and other resource files of the current page module need to be requested. After the first successful loading, the resource files of the micro-frontend will be cached locally. The next time, they will not be requested again, but will be read from the cache first. Using cached resource files not only saves bandwidth, but also achieves on-demand loading of resources and maximizes cache utilization.

[0105] In step S205, a script file is obtained based on the packaged source code file and the rendering function.

[0106] Optionally, after obtaining the packaged source code file and rendering function, a browser-supported script file is formed based on both. This script file exposes the rendered text corresponding to the source code file obtained by the target plugin. The script file can be output to the console and notify the developer. Optionally, the script file may include, but is not limited to, js files, backed-up js files, and mjs files. The js files and mjs files are micro-frontend files used to implement different loading methods. The backed-up js files are backups of the original js files to prevent loss. In an optional implementation, the step of calling the packaging module to package the source code files of at least one of the sub-applications and obtaining the script file further includes: during the packaging process, calling the target plugin to upload the associated resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

[0107] Optionally, the storage location can be, for example, a CDN (Content Delivery Network), and the corresponding target storage address can be a CDN address. The associated resource data can include dependent resource data, static resource data, and external resource data, where dependent resource data represents the dependencies between modules or components, static resource data represents resource data that does not need to be changed at runtime (e.g., CSS data, HTML data), and external resource data represents other associated data that is not bundled.

[0108] In an alternative implementation, such as Figure 4 As shown, the step of calling the target plugin to upload the associated resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address includes:

[0109] In step S401, the target plugin is invoked to point the global resource path corresponding to the source code file of at least one of the sub-applications to the target storage address.

[0110] Optionally, when implementing a Webpack-based bundler, the global resource path can be pointed to the target storage address, such as a CDN address, during a pre-run stage of the Webpack bundler process, such as the 'updateOutput' stage. For example, in the interopInitialize stage, an asynchronous updateOutput stage can be registered using the (compiler.hooks.beforeRun) method. This stage is primarily for pointing the micro-frontend's global resource path to the CDN address.

[0111] Alternatively, when implementing the Rollup packaging tool, the global resource path can be pointed to the target storage address, such as a CDN address, during the pre-configuration (configHook) stage of the Rollup packaging process. For example, in the configHook stage, the CDN address is pre-defined for subsequent use, and the global resource path is pointed to the target storage address.

[0112] In step S403, the associated resource data corresponding to the source code files of at least one of the sub-applications is obtained, and the associated resource data corresponding to the source code files of at least one of the sub-applications is uploaded to the storage location corresponding to the target storage address.

[0113] The associated resource data includes dependency resource data used to characterize the dependencies between modules or components, or static resource data used to characterize resources that do not need to be changed at runtime, and external resource data used to characterize other associated data that is not packaged. The storage location corresponding to the target storage address can be a CDN (Content Delivery Network).

[0114] Optionally, when the associated resource data includes dependent resource data, the step of obtaining the associated resource data corresponding to at least one source code file of the sub-application and uploading the associated resource data corresponding to the source code file of the at least one sub-application to the storage location corresponding to the target storage address includes:

[0115] Obtain the dependency resource data corresponding to at least one of the source code files of the sub-application;

[0116] Upload the dependency resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

[0117] In practical applications, when implementing with Webpack, associated resource data includes dependency resource data. In this case, dependency resource data can be collected and uploaded to the target storage location during the 'collectAndUploadResources' stage after the push. For example, in the interopAfterEmit stage, a promise stage (collectAndUploadResources) can be registered using the compiler.hooks.afterEmit method. This stage uses the Array.from method to iterate through the entry files of each micro-frontend component or module, obtaining their respective dependency resource files. It collects dependency resource data based on the mapping between component ID or module ID and dependency resource files, uploads the collected dependency resource data to the target storage location, and temporarily stores it in local memory for later use.

[0118] Alternatively, when the associated resource data includes static resource data and external resource data, the step of obtaining the associated resource data corresponding to at least one source code file of the sub-application and uploading the associated resource data corresponding to the source code file of at least one sub-application to the storage location corresponding to the target storage address includes:

[0119] Obtain static resource data corresponding to at least one source code file of the sub-application, and upload the static resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address;

[0120] Obtain external resource data corresponding to the source code files of at least one of the sub-applications, and upload the external resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

[0121] In practical applications, when implementing a Rollup-based bundling tool, associated resource data includes static resource data and external resource data. Taking CSS resource files as an example of static resource data, the CSS resource files can be collected and uploaded to the target storage location corresponding to the target storage address in the "write result code" (writeBundle) step. For instance, in the writeBundle step, the dependency package information in the output configuration can be read first. If the dependency package corresponds to a component entry file (isEntry), the URL of the component entry file is cached, and the CDN address and local absolute path of the component entry file are returned. Then, based on the URL of the component entry file, the corresponding CSS resource file is collected and uploaded to the target storage location corresponding to the target storage address, such as a CDN.

[0122] At this point, for external resource data, in the "Entry File Transformation" (transformIndexHtml) stage, other external resources not included in the package can be collected and uploaded to the storage location corresponding to the target storage address. For example, in the transformIndexHtml stage, the referenced external CSS files can be found by parsing the HTML file, treated as other external resources not included in the package, and uploaded to the storage location corresponding to the target storage address, such as a CDN.

[0123] In step S105, the script file is stored in the target storage location so that during the loading of the sub-application, the externally exposed rendering text can be obtained from the target storage location for rendering.

[0124] In an alternative implementation, such as Figure 5 As shown, the method further includes:

[0125] In step S501, in response to a loading instruction for a target sub-application in at least one of the sub-applications, the script file and corresponding associated resource data of the target sub-application are obtained from the target storage location;

[0126] In step S503, the rendering execution function corresponding to the micro-frontend is obtained, and the target rendering text of the target page module is obtained from the script file based on the rendering execution function; the target page module includes at least one of the page modules.

[0127] In step S505, the target rendered text and the corresponding associated resource data are loaded in the main application.

[0128] Optionally, in response to a loading instruction for a target sub-application in at least one of the sub-applications, the script file and corresponding associated resource data of the target sub-application are retrieved from the target storage location (e.g., CDN). A rendering execution function written by the developer for the micro-frontend is retrieved. This function instructs the invocation of the encapsulated interface exposed by the currently loaded rendering text of the target sub-application, and, based on this function, the target rendering text exposed by the target page module is retrieved from the script file. This target page module includes at least one page module. The target page module may include, but is not limited to, a display module, a component, or even a page display function. Next, the target rendering text and corresponding associated resource data are loaded in the main application, and the application page corresponding to the target sub-application is rendered.

[0129] Optionally, automatic file verification can be used to retrieve the code and resources corresponding to the target page module from the cache if the requested code and resources are not being requested for the first time. This avoids repeated requests. By automatically verifying file changes, the cache is maximized, resource loading time is reduced, and data processing efficiency is improved.

[0130] The above embodiments, in response to a loading instruction for a target sub-application in at least one of the sub-applications, retrieve the script file and corresponding associated resource data of the target sub-application from the target storage location; obtain the rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; the target page module includes at least one of the page modules; and load the target rendering text and corresponding associated resource data in the main application. This allows for on-demand loading and rendering of pages or partial modules, resulting in finer rendering granularity and improved flexibility in using the micro-frontend.

[0131] Optionally, loading the target rendered text and corresponding associated resource data in the main application includes:

[0132] If the loading instruction indicates a non-modular loading mode, the dynamic loading method is invoked to dynamically load the target rendered text and its corresponding associated resource data; or,

[0133] When the loading instruction indicates a modular loading mode, the native loading method is invoked to load the target rendered text and the corresponding associated resource data.

[0134] In practical applications, the non-modular loading mode can be a non-esModule loading mode, with the corresponding dynamic loading method being the `dynamicImport` method. That is, for the non-esModule loading mode, a `dynami cImport` method is provided to load JS files, uniformly obtaining the rendered text and returning it to the developer. This loading operation can be implemented using micro-frontend tools. The modular loading mode, on the other hand, can be an esModule loading mode, with the corresponding native loading method being the native `import` method. In this case, for the esModule loading mode, no other auxiliary loading tools are needed; the native `import` method can be used directly to load the .mjs file, obtain the rendered text, and return it to the developer. Developers can associate the rendering process with the rendered text, adjust the rendered text, and quickly implement on-demand rendering of the page or partial modules. This achieves controllable rendering in the micro-frontend, reduces the learning cost of the rendered text corresponding to various sub-applications integrated into the main application, results in finer rendering granularity, and makes micro-frontend applications more flexible. Furthermore, different micro-frontend loading methods are adopted for different loading modes, eliminating the need for routing binding. This decouples the micro-frontend application from routing and from the frontend framework, solving problems such as the loss of routing state after page refresh that exist in related technologies that use route hijacking to implement micro-frontends.

[0135] This embodiment of the disclosure obtains source code files for at least one sub-application used to build a micro-frontend; the at least one sub-application includes multiple page modules; a packaging module is invoked to package the source code files of the at least one sub-application to obtain a script file; the multiple page modules in the script file expose rendered text processed by a target plugin, the target plugin being integrated into the packaging module; the script file is stored in a target storage location so that during the loading of the sub-application, the exposed rendered text is retrieved from the target storage location for rendering. Thus, by invoking a packaging module integrated with a target plugin to package the source code files of at least one sub-application, the target plugin processes multiple page modules to obtain the rendered text exposed for loading the sub-application. Before packaging, there is no need to prepare multiple micro-frontend methods to process each application, and by uniformly uploading the packaged resources to the target storage location, there is no need for each micro-frontend to be published separately beforehand, simplifying the micro-frontend application process and improving the universality of micro-frontend applications.

[0136] Furthermore, unlike traditional micro-frontends limited to the page level, this disclosure intervenes from the code packaging stage, enabling micro-frontend granularity to be scaled down to the module, component, and even function level. This allows for micro-frontend granularity updates and significantly improves the flexibility of micro-frontends. Simultaneously, different micro-frontend loading methods are used for different loading modes, allowing pages to be loaded directly through micro-frontend tools without route binding. This decouples the micro-frontend application from routes and from the front-end framework, resolving issues such as route hijacking in related technologies that result in lost route state after page refresh. Additionally, the micro-frontend-based data processing method provided in this disclosure is compatible with mainstream packaging tools, covering the vast majority of front-end frameworks. It not only supports esModule and vite but also boasts low integration costs and high functional scalability.

[0137] Figure 7 This is a block diagram of a micro-frontend-based data processing apparatus according to an exemplary embodiment. (Refer to...) Figure 7 The device includes:

[0138] The first acquisition module 710 is configured to acquire source code files for building at least one sub-application of the micro-frontend; the at least one sub-application includes multiple page modules;

[0139] The first processing module 720 is configured to call the packaging module to package at least one of the source code files of the sub-application to obtain a script file; the script file includes multiple page modules exposing rendered text processed by the target plugin, and the target plugin is integrated into the packaging module;

[0140] Storage module 730 is configured to store the script file to a target storage location so that, during the loading of the sub-application, it can retrieve the externally exposed rendering text from the target storage location for rendering.

[0141] In an alternative embodiment, the apparatus further includes:

[0142] The resource acquisition module is configured to execute a loading instruction for a target sub-application in at least one of the sub-applications, and acquire the script file and corresponding associated resource data of the target sub-application from the target storage location.

[0143] The second processing module is configured to execute a rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; the target page module includes at least one of the page modules.

[0144] The loading module is configured to load the target rendered text and corresponding associated resource data in the main application.

[0145] In one alternative implementation, the loading module is specifically configured to execute:

[0146] If the loading instruction indicates a non-modular loading mode, the dynamic loading method is invoked to dynamically load the target rendered text and its corresponding associated resource data; or

[0147] When the loading instruction indicates a modular loading mode, the native loading method is invoked to load the target rendered text and the corresponding associated resource data.

[0148] In an optional embodiment, the first processing module 720 includes:

[0149] The packaging submodule is configured to execute the packaging module to package the source code files of at least one of the sub-applications;

[0150] The first processing submodule is configured to call the target plugin during the packaging process to encapsulate the rendering text corresponding to at least one source code file of the sub-application into a rendering function, wherein the rendering function is used to expose the rendering text to the outside.

[0151] The second processing submodule is configured to execute a script file based on the packaged source code file and the rendering function.

[0152] In an optional implementation, the first processing submodule 720 includes:

[0153] The code acquisition unit is configured to acquire the rendered text corresponding to at least one source code file of the sub-application;

[0154] The encapsulation unit is configured to encapsulate the acquired rendered text into a rendering function for external exposure.

[0155] In an alternative embodiment, the apparatus further includes:

[0156] The resource upload module is configured to, during the packaging process, call the target plugin to upload the associated resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address.

[0157] In one optional implementation, the resource upload module includes:

[0158] The address points to a submodule, which is configured to execute a call to the target plugin, pointing the global resource path corresponding to at least one source code file of the sub-application to the target storage address;

[0159] The upload submodule is configured to retrieve the associated resource data corresponding to the source code files of at least one of the sub-applications, and upload the associated resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

[0160] In one alternative implementation, the associated resource data includes dependency resource data for characterizing the dependencies between modules or components, or includes static resource data for characterizing that does not need to be changed at runtime, and external resource data for characterizing other associated data that is not packaged.

[0161] In an optional implementation, where the associated resource data includes dependent resource data, the upload submodule is specifically configured to execute:

[0162] Obtain the dependency resource data corresponding to at least one of the source code files of the sub-application;

[0163] Upload the dependency resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

[0164] In an optional implementation, where the associated resource data includes static resource data and external resource data, the upload submodule is specifically configured to execute:

[0165] Obtain static resource data corresponding to at least one source code file of the sub-application, and upload the static resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address;

[0166] Obtain external resource data corresponding to at least one source code file of the sub-application, and upload the external resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address.

[0167] Regarding the methods in the above embodiments, the specific manner of each step has been described in detail in the foregoing embodiments of the methods, and will not be elaborated upon here.

[0168] Figure 8 This is a block diagram illustrating another electronic device for micro-frontend-based data processing according to an exemplary embodiment. The electronic device may be a server, and its internal structure diagram may be as follows: Figure 8As shown, this electronic device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a micro-frontend-based data processing method.

[0169] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present disclosure and does not constitute a limitation on the electronic device to which the present disclosure is applied. A specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0170] In an exemplary embodiment, an electronic device is also provided, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the micro-frontend-based data processing method as described in the embodiments of this disclosure.

[0171] In an exemplary embodiment, a computer-readable storage medium is also provided, which, when executed by a processor of an electronic device, enables the electronic device to perform the steps of the method provided in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0172] In an exemplary embodiment, a computer program product is also provided, comprising a computer program / instructions that, when executed by a processor, implement the methods provided in any of the above embodiments. Optionally, the computer program is stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the methods provided in any of the above embodiments.

[0173] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0174] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0175] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A data processing method based on a micro-frontend, characterized in that, include: Obtain the source code files for at least one sub-application used to build the micro-frontend; At least one of the sub-applications includes multiple page modules; The packaging module is invoked to package the source code files of at least one of the sub-applications to obtain a script file; The script file includes multiple page modules that expose rendered text processed by the target plugin, and the target plugin is integrated into the packaging module; The script file is stored in the target storage location so that during the loading of the sub-application, the externally exposed rendering text can be obtained from the target storage location for rendering. In response to a load instruction for a target sub-application in at least one of the sub-applications, the script file and corresponding associated resource data of the target sub-application are obtained from the target storage location; Obtain the rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; The target page module includes at least one of the page modules; Load the target rendered text and corresponding associated resource data in the main application.

2. The method according to claim 1, characterized in that, The loading of the target rendered text and corresponding associated resource data in the main application includes: If the loading instruction indicates a non-modular loading mode, the dynamic loading method is invoked to dynamically load the target rendered text and its corresponding associated resource data; or, When the loading instruction indicates a modular loading mode, the native loading method is invoked to load the target rendered text and the corresponding associated resource data.

3. The method according to any one of claims 1-2, characterized in that, The process of calling the packaging module to package at least one of the source code files of the sub-application to obtain script files includes: The packaging module is invoked to package at least one of the source code files of the sub-application. During the packaging process, the target plugin is invoked to encapsulate the rendering text corresponding to at least one source code file of the sub-application into a rendering function, which is used to expose the rendering text to the outside world. The script file is obtained based on the packaged source code file and the rendering function.

4. The method according to any one of claims 1-2, characterized in that, The method further includes: During the packaging process, the target plugin is invoked to upload the associated resource data corresponding to at least one of the source code files of the sub-application to the storage location corresponding to the target storage address.

5. The method according to claim 4, characterized in that, The step of calling the target plugin to upload the associated resource data corresponding to at least one source code file of the sub-application to the storage location corresponding to the target storage address includes: Invoke the target plugin to point the global resource path corresponding to at least one of the source code files of the sub-application to the target storage address; Obtain the associated resource data corresponding to the source code files of at least one of the sub-applications, and upload the associated resource data corresponding to the source code files of at least one of the sub-applications to the storage location corresponding to the target storage address.

6. The method according to claim 4, characterized in that, The associated resource data includes dependency resource data used to characterize the dependency relationship between modules or components, or includes static resource data used to characterize the dependency relationship between modules or components, and external resource data used to characterize other associated data that are not packaged.

7. A data processing device based on a micro-frontend, characterized in that, include: The first acquisition module is configured to acquire source code files for building at least one sub-application of the micro-frontend; At least one of the sub-applications includes multiple page modules; The first processing module is configured to call the packaging module to package at least one of the source code files of the sub-application to obtain a script file; The script file includes multiple page modules that expose rendered text processed by the target plugin, and the target plugin is integrated into the packaging module; The storage module is configured to store the script file to a target storage location so that, during the loading of the sub-application, the externally exposed rendering text can be retrieved from the target storage location for rendering. The resource acquisition module is configured to execute a loading instruction for a target sub-application in at least one of the sub-applications, and acquire the script file and corresponding associated resource data of the target sub-application from the target storage location. The second processing module is configured to execute the rendering execution function corresponding to the micro-frontend, and obtain the target rendering text of the target page module from the script file based on the rendering execution function; The target page module includes at least one of the page modules; The loading module is configured to load the target rendered text and corresponding associated resource data in the main application.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the micro-frontend-based data processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the micro-frontend-based data processing method as described in any one of claims 1 to 6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the micro-frontend-based data processing method as described in any one of claims 1 to 6.

Images