A one-way data communication method, device and equipment of micro front end and storage medium

Abstract

The application discloses a one-way data communication method and device of micro front end, equipment and storage medium, belongs to research and development framework technical field. First, according to the front-end business requirement configuration and generation adapted subapplication, simultaneously for its encapsulation one-way data communication rule. Then the subapplication is loaded to micro front end framework, ensure subapplication can work with main application and other subapplication. Next, when the subapplication in micro front end framework needs communication, the system will store the communication instruction in the asynchronous message queue, and take out the instruction from the queue through the asynchronous loading mode. The system identifies the state parameters of the target subapplication in the state pool, parses the transmission parameters in the instruction, and updates the state of the target subapplication based on these parameters. The application also relates to the field of blockchain technology, and the state parameters are stored in the blockchain network. The application effectively avoids the pollution problem of the state pool, enhances the maintainability of the system, and facilitates system expansion and updating.

Description

Technical Field

[0001] This application belongs to the field of research and development framework technology, specifically relating to a micro-frontend unidirectional data communication method, device, equipment and storage medium. Background Technology

[0002] As the project progresses, the number of people involved in development, maintenance, and operation will gradually increase. This increase and turnover of personnel can lead to inconsistencies in coding style, architectural understanding, and maintenance methods, increasing the project's complexity and maintenance difficulty. Furthermore, as business grows, the front-end application needs to continuously add new features and functionalities. These new features may accumulate, making the originally simple application large and complex. When the application becomes large and complex, maintenance and updates become extremely difficult; any small change can affect other parts, leading to unforeseen errors and problems.

[0003] To address the maintenance and update challenges of front-end applications, a micro-frontends architecture is typically used to decouple and split the front-end application, allowing each sub-application to be deployed and maintained independently. Micro-frontends are a front-end architecture pattern that borrows ideas from back-end microservices, breaking down a complex, monolithic front-end application into multiple smaller front-end applications that can be developed, deployed, and maintained independently. The use of micro-frontends improves the development efficiency, flexibility, and maintainability of front-end applications, making it an effective solution for handling the complexity of large-scale front-end projects.

[0004] However, micro-frontends currently typically use the method of listening for changes in the global state to achieve data synchronization between different sub-applications. But this method can lead to state chaos and state pool pollution. For example, multiple sub-applications may modify the global state at the same time, causing state chaos and leading to unpredictable behavior and conflicts. Summary of the Invention

[0005] The purpose of this application is to propose a micro-frontend unidirectional data communication method, device, computer equipment, and storage medium to solve the technical problems of state chaos and state pool pollution caused by the method of monitoring global state changes.

[0006] To address the aforementioned technical problems, this application provides a one-way data communication method for a micro-frontend, employing the following technical solution:

[0007] A one-way data communication method for a micro-frontend, comprising:

[0008] Obtain the front-end business requirements, configure the corresponding sub-applications based on the front-end business requirements, and obtain the first target sub-application;

[0009] Generate data communication rules adapted to the first target sub-application, and encapsulate the data communication rules into the first target sub-application, wherein the data communication rules are unidirectional data communication rules;

[0010] The first target sub-application, after completing the encapsulation of data communication rules, is loaded into the preset micro-frontend framework;

[0011] In response to the data communication needs of the second target sub-application, obtain the data communication instructions and store the data communication instructions in a preset asynchronous message queue;

[0012] Data communication instructions are loaded from an asynchronous message queue using an asynchronous loading method, and the state parameters corresponding to the second target sub-application are identified in a preset state pool;

[0013] Parse the data communication instructions, obtain the transmitted parameters, and update the status parameters corresponding to the second target sub-application based on the transmitted parameters.

[0014] To address the aforementioned technical problems, this application also provides a micro-frontend unidirectional data communication device, which employs the following technical solution:

[0015] A micro-frontend unidirectional data communication device, comprising:

[0016] The sub-application configuration module is used to obtain front-end business requirements, configure the corresponding sub-applications according to the front-end business requirements, and obtain the first target sub-application.

[0017] The communication rule configuration module is used to generate data communication rules adapted to the first target sub-application and encapsulate the data communication rules into the first target sub-application. The data communication rules are unidirectional data communication rules.

[0018] The sub-application loading module is used to load the first target sub-application, which has completed the encapsulation of data communication rules, into the preset micro-frontend framework;

[0019] The instruction asynchronous storage module is used to respond to the data communication needs of the second target sub-application, obtain data communication instructions, and store the data communication instructions in a preset asynchronous message queue.

[0020] The instruction asynchronous loading module is used to load data communication instructions from the asynchronous message queue in an asynchronous manner, and identify the state parameters corresponding to the second target sub-application in a preset state pool;

[0021] The status parameter update module is used to parse the data communication command, obtain the transmitted parameters, and update the status parameters corresponding to the second target sub-application based on the transmitted parameters.

[0022] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution:

[0023] A computer device includes a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the one-way data communication method of the micro-frontend as described in any of the preceding claims.

[0024] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below:

[0025] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of a one-way data communication method for a micro-frontend as described in any of the preceding descriptions.

[0026] Compared with the prior art, the embodiments of this application have the following main advantages:

[0027] This application discloses a one-way data communication method, apparatus, device, and storage medium for a micro-frontend, belonging to the field of R&D framework technology. First, an adapted sub-application is configured and generated according to frontend business requirements, and one-way data communication rules are encapsulated for it. Then, the sub-application is loaded into the micro-frontend framework, ensuring that it can work collaboratively with the main application and other sub-applications. Next, when a sub-application in the micro-frontend framework needs to communicate, the system stores the communication instructions in an asynchronous message queue and retrieves the instructions from the queue asynchronously. The system identifies the state parameters of the target sub-application in the state pool, parses the parameters passed in the instructions, and updates the state of the target sub-application based on these parameters. This application, through one-way data communication, strictly controls the sub-application's access to the main application's state pool, avoiding state pollution caused by sub-applications arbitrarily modifying the main application's state pool. Sub-applications can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operational costs, improving data management efficiency, and enhancing the system's maintainability and overall stability and scalability under the micro-frontend architecture through high decoupling between the sub-application and the main application. At the same time, the asynchronous loading method is used to handle data communication between various sub-applications, which can load and process tasks on demand and avoid unnecessary performance overhead. Attached Figure Description

[0028] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 An exemplary system architecture diagram is shown, in which this application can be applied;

[0030] Figure 2 A flowchart illustrating one embodiment of the micro-frontend unidirectional data communication method according to this application is shown;

[0031] Figure 3 A schematic diagram of the structure of one embodiment of a micro-frontend unidirectional data communication device according to this application is shown;

[0032] Figure 4 A schematic diagram of the structure of one embodiment of a computer device according to this application is shown. Detailed Implementation

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0034] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

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

[0036] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0037] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0038] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers.

[0039] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0040] It should be noted that the one-way data communication method of the micro-frontend provided in this application embodiment is generally executed by the server / terminal device, and correspondingly, the one-way data communication device of the micro-frontend is generally set in the server / terminal device.

[0041] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative; the system can have any number of terminal devices, networks, and servers depending on implementation needs.

[0042] Continue to refer to Figure 2 A flowchart illustrating an embodiment of a one-way data communication method for a micro-frontend according to this application is shown. The one-way data communication method for the micro-frontend includes the following steps:

[0043] S201, Obtain front-end business requirements, configure corresponding sub-applications based on front-end business requirements, and obtain the first target sub-application.

[0044] Specifically, obtaining front-end business requirements refers to clarifying the interface display and interaction logic based on user needs or specific system functional requirements. Business requirements can come from user feedback, market research, or detailed descriptions in product design documents. Based on these business requirements, the development team needs to determine the sub-applications that need to be configured, specifically including determining the functional scope, interaction mode, and communication methods with other sub-applications.

[0045] In a micro-frontend architecture, sub-applications are independent modules, each responsible for a specific business function. By analyzing business requirements, selecting appropriate technology stacks and modular tools to configure sub-applications, and determining their communication interfaces with other sub-applications or the main framework, a first target sub-application suitable for a specific scenario is obtained. The high degree of decoupling between sub-applications and the main application enhances the maintainability of the system and improves the overall stability and scalability under the micro-frontend architecture.

[0046] S202, Generate data communication rules adapted to the first target sub-application, and encapsulate the data communication rules into the first target sub-application, wherein the data communication rules are unidirectional data communication rules.

[0047] Specifically, when generating data communication rules, the independence and flexibility of the micro-frontend architecture need to be considered. The core function of data communication rules is to specify how data is transferred and updated between sub-applications and the main application. For unidirectional data communication rules, the characteristic is that data can only flow in a fixed direction, typically from the parent application to the sub-application, or from the sub-application to the main application. The advantage of unidirectional data communication is that it ensures the controllability of the data flow, reduces the uncertainty and complexity caused by bidirectional data binding, thereby mitigating state pollution problems.

[0048] When configuring one-way data communication rules, it is also necessary to consider the data format, data verification, and error handling mechanisms to ensure the security and stability of communication. Finally, these rules are encapsulated into the code of the first target sub-application, enabling it to communicate with other modules at runtime in a predefined manner.

[0049] In one specific embodiment of this application, the one-way data communication rule is implemented based on the one-way data communication method postMessageToBaseApp. The postMessageToBaseApp method is a mechanism used in a micro-frontend architecture to realize communication between sub-applications and main applications. By sending messages, the sub-application can transmit data to the main application, but the data flow is limited to the one-way channel from the sub-application to the main application. That is, the sub-application can only send information to the main application, but cannot directly read or modify the state of the main application.

[0050] S203 loads the first target sub-application, which has completed the encapsulation of data communication rules, into the preset micro-frontend framework.

[0051] Specifically, in a micro-frontend architecture, the framework typically plays the role of managing and coordinating multiple sub-applications. After being encapsulated, each sub-application needs to be loaded into a unified micro-frontend framework to work collaboratively with other sub-applications. The loading process involves injecting the sub-application's resources (such as HTML, CSS, and JavaScript files) into the framework's execution environment and ensuring that these resources are loaded on demand to avoid unnecessary resource waste and performance issues.

[0052] Furthermore, during the loading process, the system also needs to ensure that the initialization process of the sub-application is completed normally, including the activation of its data communication rules, the registration of event listeners, and the initialization of its state. Through the coordination of the micro-frontend framework, efficient communication and functional collaboration can be achieved between the sub-application, the framework, and other sub-applications.

[0053] S204, responding to the data communication needs of the second target sub-application, obtains the data communication instruction and stores the data communication instruction in a preset asynchronous message queue.

[0054] Specifically, when the second target sub-application issues a data communication request, the system needs to process it accordingly. The second target sub-application can be any sub-application in the micro-frontend architecture. Data communication requests typically manifest as the sub-application wanting to exchange data or update its state with other modules.

[0055] The system generates corresponding data communication instructions based on data communication requirements. These instructions include the operation type, relevant data, and the identifier of the target module. To support the asynchronous communication mechanism of the micro-frontend system, enable on-demand task loading, and avoid unnecessary performance overhead, these data communication instructions are not executed immediately but are stored in an asynchronous message queue. The existence of the asynchronous message queue ensures the non-blocking nature of the communication process, preventing delays or blockages in data communication from affecting the normal operation of other functions. The design of the asynchronous message queue allows for loosely coupled data exchange between sub-applications and improves the responsiveness and scalability of the entire system.

[0056] S205 uses an asynchronous loading method to load data communication instructions from an asynchronous message queue and identifies the state parameters corresponding to the second target sub-application in a preset state pool.

[0057] Specifically, communication instructions stored in the asynchronous message queue are loaded asynchronously according to the system's scheduling mechanism. The system retrieves these instructions from the message queue at appropriate times and processes them step by step. The first step in processing is to parse the instruction content to clarify the sub-application and state update requirements targeted by the instruction. By comparing it with a preset state pool, the system can identify the state parameters currently used by the second target sub-application.

[0058] A state pool is typically a centralized area that stores the states of various sub-applications within a system, ensuring that multiple sub-applications share the same state in terms of visibility and consistency. In this scenario, the data in the state pool is dynamic, updating as communication commands are executed. This approach ensures that communication latency is mitigated without impacting the system's real-time performance.

[0059] S206, parse the data communication command, obtain the transmitted parameters, and update the status parameters corresponding to the second target sub-application based on the transmitted parameters.

[0060] Specifically, after a data communication command is loaded from the asynchronous message queue, the system needs to parse the command to obtain the specific transmission parameters it carries. The parsing process involves operations such as decoding, data format conversion, and parameter verification to ensure the integrity and correctness of the transmitted parameters.

[0061] Next, the system updates the current state of the second target sub-application based on these transmitted parameters. State updates typically manifest as changes in the state of certain UI elements, interaction logic, or functionalities within the sub-application. By applying the transmitted parameters, the sub-application's behavior adjusts responsively, thereby achieving data synchronization with other sub-applications or frameworks. Throughout this process, the unidirectional data communication mechanism ensures deterministic data flow, avoiding problems caused by state inconsistencies or conflicts. The ultimate goal of this update process is to maintain the overall coordination of the system and data consistency.

[0062] In the above embodiments, this application strictly controls sub-applications' access to the main application's state pool through unidirectional data communication, avoiding state pollution caused by sub-applications arbitrarily modifying the main application's state pool. Sub-applications can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operational costs, improving data management efficiency, and enhancing the high decoupling between sub-applications and the main application. This also improves system maintainability and enhances the overall stability and scalability of the micro-frontend architecture. Furthermore, the asynchronous loading method for handling data communication between sub-applications enables on-demand loading and processing of tasks, avoiding unnecessary performance overhead.

[0063] Furthermore, the steps of generating data communication rules adapted to the first target sub-application and encapsulating the data communication rules into the first target sub-application specifically include:

[0064] Determine the data transmission direction of the first target sub-application and the parent application of the first target sub-application based on the front-end business requirements.

[0065] Determine the data transmission path based on the first target sub-application and its parent application;

[0066] Generate one-way data communication rules adapted to the first target sub-application based on the data transmission direction and data transmission path.

[0067] In this embodiment, the system first analyzes the front-end business requirements to determine the specific data transmission direction of the first target sub-application. Specifically, the system needs to clarify whether the sub-application only needs to receive and send data, or whether it exchanges data with the parent application through unidirectional data flow. Determining the data transmission direction is the foundation for formulating the entire data communication rule, defining the interaction mode between the sub-application and the main application. Next, the system further confirms the parent application of the first target sub-application. The parent application is typically a core module responsible for coordinating multiple sub-applications, receiving and processing data requests from the sub-applications. Confirming the parent application helps establish a master-slave relationship, ensuring a clear hierarchical structure for the communication.

[0068] Then, based on the relationship between the sub-application and its parent application, the system generates a data transfer path. This path defines how data flows from the sub-application to the parent application, emphasizing unidirectional data flow. Finally, based on the data transfer direction and path, the system generates a set of unidirectional data communication rules adapted to the first target sub-application. These rules ensure that the sub-application's communication follows the predefined path and direction, guaranteeing data integrity and security while preventing state contamination.

[0069] Through the above steps, suitable one-way data communication rules are effectively generated for the first target sub-application, ensuring that data flows between applications in a clear direction and avoiding data conflicts or state pollution problems.

[0070] Furthermore, the step of loading the first target sub-application, which has completed the encapsulation of data communication rules, into the preset micro-frontend framework specifically includes:

[0071] Identify the position of the parent application within the micro-frontend framework to obtain the parent application's position information;

[0072] Calculate the position of the first target sub-application in the micro-frontend framework based on the parent application's position information, and obtain the sub-application's position information;

[0073] Based on the sub-application location information, the first target sub-application is loaded onto the micro-frontend framework.

[0074] In this embodiment, the system first identifies the position of the parent application within the micro-frontend framework to obtain its location information. This location information typically includes the parent application's hierarchy and physical location within the overall layout. Next, based on the parent application's location information, the system calculates the relative position of the first target sub-application within the micro-frontend framework, obtaining the sub-application's specific location information. This calculation process ensures that the sub-application can be nested and coordinated appropriately with the parent application according to predetermined logic and layout. Finally, based on the calculated location information, the first target sub-application is correctly loaded into the micro-frontend framework, enabling it to collaborate with other modules in a suitable context.

[0075] By following the steps above, we can ensure that sub-applications are loaded accurately, thus guaranteeing the rationality and integrity of the system module layout.

[0076] Furthermore, before the steps of responding to the data communication needs of the second target sub-application, obtaining the data communication instruction, and storing the data communication instruction in a preset asynchronous message queue, the method further includes:

[0077] The sub-applications with data communication requirements in the micro-frontend framework are identified as the second target sub-applications;

[0078] The data transmission direction of the second target sub-application and the parent application of the second target sub-application are determined based on data communication requirements.

[0079] Based on the one-way data communication rules and the data transmission direction of the second target sub-application, a one-way data communication channel is constructed between the second target sub-application and its parent application.

[0080] The second target sub-application is instructed to upload data communication commands through a one-way data communication channel.

[0081] In this embodiment, the system first detects sub-applications within the micro-frontend framework that have data communication needs and identifies them as the second target sub-applications. This is typically based on business logic requirements or internal application state changes; for example, a sub-application might need to send information to the main application or other sub-applications. Next, the system determines the data transmission direction of the second target sub-application based on the data communication requirements. Simultaneously, the parent application is also identified as either the receiver or the initiator of the data communication.

[0082] Based on this, the system relies on preset one-way data communication rules and, combined with the data transmission direction, establishes a one-way data communication channel between the second target sub-application and the parent application. This channel ensures that data can only flow in the set direction, avoiding the complexity and state conflict issues caused by two-way communication. Finally, the system instructs the second target sub-application to upload communication commands through this one-way data communication channel. These commands can be specific business data, state update requests, or event trigger information, and the main application or parent application responds accordingly based on the received commands.

[0083] Through the above steps, the system achieves strict unidirectional data transmission between child applications and parent applications, ensuring the orderliness and security of the data communication channel, avoiding state pollution problems, and improving the reliability and maintainability of the system.

[0084] Furthermore, the steps of parsing the data communication instructions, obtaining the transmitted parameters, and updating the status parameters corresponding to the second target sub-application based on the transmitted parameters specifically include:

[0085] The data communication instructions are decoded, and the transmission parameters are filtered from the decoded data. The transmission parameters include communication topic parameters and communication content carrier parameters.

[0086] Based on the communication topic parameters and communication content carrier parameters, determine the status of the second target sub-application;

[0087] Update the status parameters of the second target sub-application according to its state.

[0088] In this embodiment, the system first decodes the received data communication instructions, extracting the valid information. Through decoding, the system can filter out the transmission parameters from the original instructions. These parameters mainly include communication topic parameters and communication content carrier parameters. The communication topic parameters identify the intent or purpose of this communication, while the communication content carrier parameters carry the specific data content. Next, based on the parsed communication topic and content carrier, the system determines the state of the second target sub-application. A clear state allows the sub-application to clearly understand its current business context and perform corresponding processing accordingly. Finally, the system updates the corresponding state parameters of the second target sub-application based on its state.

[0089] By following the steps above, we can ensure that sub-applications can accurately receive and process data communication commands, improve the timeliness and accuracy of status updates, and enhance the overall flexibility and responsiveness of the system.

[0090] Furthermore, the communication topic parameters include a first communication topic, a second communication topic, and a third communication topic, and the communication content carrier parameters include a first content carrier, a second content carrier, and a third content carrier. The step of determining the state of the second target sub-application based on the communication topic parameters and the communication content carrier parameters specifically includes:

[0091] When the communication topic parameter is the first communication topic and the communication content carrier parameter is the first content carrier, the state of the second target sub-application is determined to be the session timeout state.

[0092] When the communication topic parameter is the second communication topic and the communication content carrier parameter is the first content carrier, the state of the second target sub-application is determined to be the identifier loading state.

[0093] When the communication topic parameter is the third communication topic and the communication content carrier parameter is the second or third content carrier, the state of the second target sub-application is determined to be the page jump state.

[0094] In this embodiment, the system dynamically determines the status of the second target sub-application by parsing the transmitted parameters and considering different communication topic parameters and content carrier parameters. Specifically, when the communication topic parameter is the first communication topic and the communication content carrier parameter is the first content carrier, the system identifies the status of the second target sub-application as a session timeout state. That is, the system will prompt the user that their session has expired and they need to log in again, thus enhancing system security and user experience.

[0095] When the communication topic parameter is the second communication topic, but the communication content carrier parameter remains the first content carrier, the sub-application's state is determined to be in a loading state. This loading state indicates that the sub-application is loading or processing data, and the user interface may display a loading animation or progress bar to prompt the user to wait patiently. Switching between loading states ensures that users receive visual feedback while waiting, thereby reducing anxiety caused by loading.

[0096] Finally, when the communication topic parameter is the third communication topic and the communication content carrier parameter is the second or third content carrier, the system will mark the sub-application's status as a page jump state. In this case, the system will process the page jump request to ensure that the user can smoothly navigate to the new page or functional module.

[0097] Through the above steps, accurate judgment and dynamic response to the state of sub-applications are achieved, enabling them to flexibly adjust their own state according to different communication topics and content carriers, thereby improving the timeliness and effectiveness of user interaction.

[0098] Furthermore, the step of updating the state parameters corresponding to the second target sub-application based on its state specifically includes:

[0099] Obtain the status parameters corresponding to the session timeout state to get the first update parameter;

[0100] The first update parameter is used to update the state parameter corresponding to the second target sub-application;

[0101] Obtain the status parameters corresponding to the loading status to get the second update parameters;

[0102] The second update parameter is used to update the state parameters corresponding to the second target sub-application;

[0103] Obtain the status parameters corresponding to the page transition state to get the third update parameter;

[0104] The third update parameter is used to update the corresponding state parameters of the second target sub-application.

[0105] In this embodiment, the system acquires state parameters for different states to ensure that the second target sub-application can accurately update its state according to actual needs. First, the system acquires state parameters corresponding to the session timeout state. These parameters include user notification messages, timeout countdown information, etc., and stores them as first update parameters. Next, the system uses the first update parameters to update the state parameters of the second target sub-application, ensuring that the user receives the appropriate notification and performs the corresponding action, such as re-login, when the session times out.

[0106] Subsequently, the system retrieves the status parameters corresponding to the loading status, obtaining the second update parameters. These parameters include the display status of the loading animation and progress bar information, aiming to inform the user that the system is processing the request. The second update parameters are then used to update the status parameters of the second target sub-application, ensuring a smooth user experience.

[0107] Finally, the system retrieves the status parameters corresponding to the page redirection state, obtaining the third update parameters. At this point, the status parameters include the new page address, routing information, and redirection conditions. The third update parameters are used to update the status parameters of the second target sub-application, ensuring that it can redirect the page at the appropriate time and under the appropriate conditions.

[0108] Through the above steps, the state of the second target sub-application is effectively managed, enabling it to respond promptly to session timeouts, loading statuses, and page redirections, thereby improving system flexibility and user satisfaction.

[0109] In one specific embodiment of this application, the postMessageToBaseApp method is used to implement unidirectional data communication between the main application and the sub-application in a micro-frontend architecture. The postMessageToBaseApp method provides a communication channel between the main and sub-applications, similar to the postMessage method in a browser environment. Its purpose is to allow the sub-application to send information to the main application, triggering specific functions or operations. This design employs a unidirectional data communication mechanism, meaning that data is only sent from the sub-application to the main application, rather than through bidirectional interaction. This helps simplify data flow and avoids complex bidirectional data synchronization and potential state conflicts.

[0110] The postMessageToBaseApp method provides two key parameters: theme (communication topic parameter) and param (communication content carrier parameter), which are used to define the communication topic and the data to be transmitted.

[0111] The theme, as a communication topic, defines the context and type of information sent by a sub-application to the main application. Different theme values ​​in different scenarios will trigger different response behaviors from the main application. The theme is essentially a predefined event identifier, and the main application will select the appropriate processing logic based on the theme value.

[0112] As a carrier of communication content, param transmits specific data related to the theme. Depending on the theme, param can be a boolean value, a string, or a more complex JSON object, used to provide additional information required by the main application to perform corresponding operations.

[0113] When the theme value is loginTimeOut (the first communication topic) and param is true (the first content carrier), the sub-application notifies the main application that the user's session has timed out. Based on the received information, the main application will activate the session timeout notification function, displaying a prompt or guiding the user to log in again. This communication method ensures that the main application can centrally manage the user's login status, while the sub-application only needs to send a simple command to complete the operation. This simplifies the sub-application's logic, freeing it from managing the details of session state; it only needs to send a session timeout notification.

[0114] When the theme is "loading" (secondary communication theme) and param is true (primary content carrier), the sub-application notifies the main application to enter the "loading" state via this message. The main application will then display a global loading animation or progress bar to inform the user that data is being loaded. Conversely, if param is false, the loading state can be terminated. This approach allows the main application to centrally manage the loading state of the entire system, preventing multiple sub-applications from displaying inconsistent loading animations, thereby improving the consistency of the user experience.

[0115] When the theme is `jumpCertainUrl` (the third communication theme) and `param` is a transaction code string (the second content carrier) or a JSON object containing a transaction code and other parameters (the third content carrier), the sub-application notifies the main application to perform a page redirection operation via the `jumpCertainUrl` theme. `param` can be a transaction code string or a JSON object containing a transaction code and other parameters. The main application determines the target page based on the transmitted transaction code. The transaction code may correspond to a specific business function or page module, while additional parameters in the JSON object (such as `bsnCode` and `otherParams`) can provide additional page context or customized redirection logic. This design provides a concise and flexible way for sub-applications to relinquish navigation control to the main application, ensuring consistency and security in redirection operations.

[0116] The above-described implementation provides flexible scalability; the theme can be expanded to include more communication topics to adapt to different business scenarios. By adding different theme values, sub-applications can interact with the main application in more dimensions, and the behavior of each theme can be dynamically adjusted according to requirements. Furthermore, the design of the param parameter is also very flexible; it can be a simple boolean value or a complex JSON object to adapt to data transmission needs of varying complexity.

[0117] In the above embodiments, this application discloses a one-way data communication method for micro-frontends, belonging to the field of R&D framework technology. First, an adapted sub-application is configured and generated according to frontend business requirements, and one-way data communication rules are encapsulated for it. Then, the sub-application is loaded into the micro-frontend framework, ensuring that the sub-application can work collaboratively with the main application and other sub-applications. Next, when a sub-application in the micro-frontend framework needs to communicate, the system stores the communication instructions in an asynchronous message queue and retrieves the instructions from the queue asynchronously. The system identifies the state parameters of the target sub-application in the state pool, parses the parameters passed in the instructions, and updates the state of the target sub-application based on these parameters. This application, through one-way data communication, strictly controls the sub-application's access to the main application's state pool, avoiding the state pollution problem caused by the sub-application arbitrarily modifying the main application's state pool. The sub-application can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operation costs, improving data management efficiency, and the high decoupling between the sub-application and the main application enhances the maintainability of the system and improves the overall stability and scalability under the micro-frontend architecture. At the same time, the asynchronous loading method is used to handle data communication between various sub-applications, which can load and process tasks on demand and avoid unnecessary performance overhead.

[0118] In this embodiment, the micro-frontend's one-way data communication method operates on an electronic device (e.g., Figure 1 The server shown can receive instructions or acquire data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods.

[0119] It should be emphasized that, to further ensure the privacy and security of the aforementioned state parameter information, this state parameter information can also be stored in a blockchain node.

[0120] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0121] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0122] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0123] 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 instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0124] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0125] Further reference Figure 3 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a micro-frontend unidirectional data communication device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0126] like Figure 3 As shown, the unidirectional data communication device 300 of the micro-frontend described in this embodiment includes:

[0127] Sub-application configuration module 301 is used to obtain front-end business requirements, configure corresponding sub-applications according to front-end business requirements, and obtain the first target sub-application.

[0128] The communication rule configuration module 302 is used to generate data communication rules adapted to the first target sub-application and encapsulate the data communication rules into the first target sub-application, wherein the data communication rules are unidirectional data communication rules;

[0129] The sub-application loading module 303 is used to load the first target sub-application, which has completed the encapsulation of data communication rules, into the preset micro-frontend framework;

[0130] The instruction asynchronous storage module 304 is used to respond to the data communication needs of the second target sub-application, obtain data communication instructions, and store the data communication instructions in a preset asynchronous message queue.

[0131] The instruction asynchronous loading module 305 is used to load data communication instructions from the asynchronous message queue in an asynchronous loading manner, and identify the state parameters corresponding to the second target sub-application in a preset state pool;

[0132] The status parameter update module 306 is used to parse the data communication command, obtain the transmitted parameters, and update the status parameters corresponding to the second target sub-application based on the transmitted parameters.

[0133] Furthermore, the communication rule configuration module 302 is specifically used for:

[0134] Based on the front-end business requirements, determine the data transmission direction of the first target sub-application and its parent application; based on the first target sub-application and its parent application, determine the data transmission path; and generate unidirectional data communication rules adapted to the first target sub-application based on the data transmission direction and data transmission path.

[0135] Furthermore, the sub-application loading module 303 is specifically used for:

[0136] Identify the position of the parent application within the micro-frontend framework to obtain the parent application's position information; calculate the position of the first target sub-application within the micro-frontend framework based on the parent application's position information to obtain the sub-application's position information; and load the first target sub-application onto the micro-frontend framework based on the sub-application's position information.

[0137] Furthermore, the micro-frontend unidirectional data communication device 300 also includes a communication command uploading module, which is specifically used for:

[0138] The sub-application with data communication requirements in the micro-frontend framework is identified as the second target sub-application; the data transmission direction of the second target sub-application and its parent application are determined based on the data communication requirements; a one-way data communication channel is constructed between the second target sub-application and its parent application based on the one-way data communication rules and the data transmission direction of the second target sub-application; and the second target sub-application is instructed to upload data communication instructions through the one-way data communication channel.

[0139] Furthermore, the state parameter update module 306 is specifically used for:

[0140] The data communication command is decoded, and the transmission parameters are filtered from the decoded data. The transmission parameters include communication topic parameters and communication content carrier parameters. Based on the communication topic parameters and communication content carrier parameters, the state of the second target sub-application is determined. Based on the state of the second target sub-application, the state parameters corresponding to the second target sub-application are updated.

[0141] Furthermore, the communication topic parameters include a first communication topic, a second communication topic, and a third communication topic; the communication content carrier parameters include a first content carrier, a second content carrier, and a third content carrier; and the status parameter update module 306 is further used for:

[0142] When the communication topic parameter is the first communication topic and the communication content carrier parameter is the first content carrier, the state of the second target sub-application is determined to be the session timeout state; when the communication topic parameter is the second communication topic and the communication content carrier parameter is the first content carrier, the state of the second target sub-application is determined to be the identifier loading state; when the communication topic parameter is the third communication topic and the communication content carrier parameter is the second content carrier or the third content carrier, the state of the second target sub-application is determined to be the page redirection state.

[0143] Furthermore, the state parameter update module 306 is further used for:

[0144] Get the status parameters corresponding to the session timeout state to obtain the first update parameter; use the first update parameter to update the status parameters corresponding to the second target sub-application; get the status parameters corresponding to the loading state to obtain the second update parameter; use the second update parameter to update the status parameters corresponding to the second target sub-application; get the status parameters corresponding to the page jump state to obtain the third update parameter; use the third update parameter to update the status parameters corresponding to the second target sub-application.

[0145] In the above embodiments, this application discloses a one-way data communication device for a micro-frontend, belonging to the field of R&D framework technology. First, an adapted sub-application is configured and generated according to frontend business requirements, and one-way data communication rules are encapsulated for it. Then, the sub-application is loaded into the micro-frontend framework, ensuring that the sub-application can work collaboratively with the main application and other sub-applications. Next, when a sub-application in the micro-frontend framework needs to communicate, the system stores the communication instruction in an asynchronous message queue and retrieves the instruction from the queue asynchronously. The system identifies the state parameters of the target sub-application in the state pool, parses the transmitted parameters in the instruction, and updates the state of the target sub-application based on these parameters. This application, through one-way data communication, strictly controls the sub-application's access to the main application's state pool, avoiding the state pollution problem caused by the sub-application arbitrarily modifying the main application's state pool. The sub-application can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operation costs, improving data management efficiency, and the high decoupling between the sub-application and the main application enhances the system's maintainability and improves the overall stability and scalability under the micro-frontend architecture. At the same time, the asynchronous loading method is used to handle data communication between various sub-applications, which can load and process tasks on demand and avoid unnecessary performance overhead.

[0146] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0147] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with memory 41, processor 42, and network interface 43 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0148] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0149] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for a micro-frontend unidirectional data communication method. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0150] In some embodiments, the processor 42 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions for the one-way data communication method of the micro-front end.

[0151] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0152] In the above embodiments, this application discloses a computer device belonging to the field of R&D framework technology. First, an adapted sub-application is configured and generated according to front-end business requirements, and unidirectional data communication rules are encapsulated for it. Then, the sub-application is loaded into the micro-frontend framework to ensure that it can work collaboratively with the main application and other sub-applications. Next, when a sub-application in the micro-frontend framework needs to communicate, the system stores the communication instructions in an asynchronous message queue and retrieves the instructions from the queue asynchronously. The system identifies the state parameters of the target sub-application in the state pool, parses the parameters passed in the instructions, and updates the state of the target sub-application based on these parameters. This application, through unidirectional data communication, strictly controls the sub-application's access to the main application's state pool, avoiding the state pollution problem caused by the sub-application arbitrarily modifying the main application's state pool. The sub-application can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operation costs, improving data management efficiency, and the high decoupling between the sub-application and the main application enhances the system's maintainability and improves the overall stability and scalability under the micro-frontend architecture. At the same time, the asynchronous loading method is used to handle data communication between various sub-applications, which can load and process tasks on demand and avoid unnecessary performance overhead.

[0153] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the micro-frontend unidirectional data communication method as described above.

[0154] In the above embodiments, this application discloses a computer-readable storage medium, belonging to the field of R&D framework technology. First, an adapted sub-application is configured and generated according to front-end business requirements, and unidirectional data communication rules are encapsulated for it. Then, the sub-application is loaded into the micro-frontend framework, ensuring that the sub-application can work collaboratively with the main application and other sub-applications. Next, when a sub-application in the micro-frontend framework needs to communicate, the system stores the communication instructions in an asynchronous message queue and retrieves the instructions from the queue asynchronously. The system identifies the state parameters of the target sub-application in the state pool, parses the transmitted parameters in the instructions, and updates the state of the target sub-application based on these parameters. This application, through unidirectional data communication, strictly controls the sub-application's access to the main application's state pool, avoiding the state pollution problem caused by the sub-application arbitrarily modifying the main application's state pool. The sub-application can only operate the state pool through specific methods exposed by the main application, thereby reducing communication and operation costs, improving data management efficiency, and the high decoupling between the sub-application and the main application enhances the system's maintainability and improves the overall stability and scalability under the micro-frontend architecture. At the same time, the asynchronous loading method is used to handle data communication between various sub-applications, which can load and process tasks on demand and avoid unnecessary performance overhead.

[0155] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0156] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0157] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A one-way data communication method for a micro-frontend, characterized in that, include: Obtain the front-end business requirements, configure the corresponding sub-applications according to the front-end business requirements, and obtain the first target sub-application; Generate data communication rules adapted to the first target sub-application, and encapsulate the data communication rules into the first target sub-application. The data communication rules are one-way data communication rules, which limit data flow to only from the sub-application to the main application. The sub-application can only send information to the main application. The first target sub-application, after completing the encapsulation of data communication rules, is loaded into the preset micro-frontend framework; In response to the data communication needs of the second target sub-application, a data communication instruction is obtained and stored in a preset asynchronous message queue; The data communication instruction is loaded from the asynchronous message queue using an asynchronous loading method, and the state parameters corresponding to the second target sub-application are identified in a preset state pool; The data communication instruction is parsed to obtain the transmission parameters carried, and the status parameters corresponding to the second target sub-application are updated based on the transmission parameters. The step of generating data communication rules adapted to the first target sub-application and encapsulating the data communication rules into the first target sub-application specifically includes: The data transmission direction of the first target sub-application and the parent application of the first target sub-application are determined based on the aforementioned front-end business requirements. Determine the data transmission path based on the first target sub-application and its parent application; Generate a one-way data communication rule adapted to the first target sub-application based on the data transmission direction and the data transmission path; Before the steps of responding to the data communication request of the second target sub-application, obtaining the data communication instruction, and storing the data communication instruction in a preset asynchronous message queue, the method further includes: The sub-applications that have data communication requirements in the micro-frontend framework are identified as the second target sub-applications; The data transmission direction of the second target sub-application and the parent application of the second target sub-application are determined based on the data communication requirements. Based on the unidirectional data communication rules and the data transmission direction of the second target sub-application, a unidirectional data communication channel is constructed between the second target sub-application and its parent application. The second target sub-application is instructed to upload the data communication command through the one-way data communication channel.

2. The one-way data communication method for a micro-frontend as described in claim 1, characterized in that, The step of loading the first target sub-application, after completing the data communication rule encapsulation, into the preset micro-frontend framework specifically includes: Identify the position of the parent application within the micro-frontend framework to obtain the parent application's position information; Calculate the position of the first target sub-application in the micro-frontend framework based on the parent application's position information to obtain the sub-application's position information; Based on the sub-application location information, the first target sub-application is loaded onto the micro-frontend framework.

3. The one-way data communication method for a micro-frontend as described in claim 1, characterized in that, The step of parsing the data communication instruction, obtaining the carried transmission parameters, and updating the status parameters corresponding to the second target sub-application based on the transmission parameters specifically includes: The data communication command is decoded, and the transmission parameters are filtered from the decoded data, wherein the transmission parameters include communication topic parameters and communication content carrier parameters; The state of the second target sub-application is determined based on the communication topic parameters and the communication content carrier parameters. Based on the state of the second target sub-application, update the state parameters corresponding to the second target sub-application.

4. The one-way data communication method for a micro-frontend as described in claim 3, characterized in that, The communication topic parameters include a first communication topic, a second communication topic, and a third communication topic; the communication content carrier parameters include a first content carrier, a second content carrier, and a third content carrier; the step of determining the state of the second target sub-application based on the communication topic parameters and the communication content carrier parameters specifically includes: When the communication topic parameter is a first communication topic and the communication content carrier parameter is a first content carrier, the state of the second target sub-application is determined to be a session timeout state. When the communication topic parameter is the second communication topic and the communication content carrier parameter is the first content carrier, the state of the second target sub-application is determined to be the identifier loading state. When the communication topic parameter is a third communication topic and the communication content carrier parameter is a second content carrier or a third content carrier, the state of the second target sub-application is determined to be a page jump state.

5. The one-way data communication method for a micro-frontend as described in claim 4, characterized in that, The step of updating the state parameters of the second target sub-application according to its state specifically includes: Obtain the status parameters corresponding to the session timeout state to obtain the first update parameters; The first update parameter is used to update the state parameter corresponding to the second target sub-application; Obtain the status parameters corresponding to the identifier loading status to obtain the second update parameters; The status parameters corresponding to the second target sub-application are updated using the second update parameters. Obtain the status parameters corresponding to the page jump state to get the third update parameter; The third update parameter is used to update the state parameters corresponding to the second target sub-application.

6. A micro-frontend unidirectional data communication device, characterized in that, The unidirectional data communication device implements the steps of the unidirectional data communication method for the micro-frontend as described in any one of claims 1 to 5, wherein the unidirectional data communication device comprises: The sub-application configuration module is used to obtain front-end business requirements, configure corresponding sub-applications according to the front-end business requirements, and obtain the first target sub-application. A communication rule configuration module is used to generate data communication rules adapted to the first target sub-application and encapsulate the data communication rules into the first target sub-application, wherein the data communication rules are one-way data communication rules; The sub-application loading module is used to load the first target sub-application, which has completed the encapsulation of data communication rules, into a preset micro-frontend framework; An asynchronous instruction storage module is used to respond to the data communication needs of the second target sub-application, obtain data communication instructions, and store the data communication instructions in a preset asynchronous message queue. An asynchronous instruction loading module is used to load the data communication instruction from the asynchronous message queue in an asynchronous manner, and to identify the state parameters corresponding to the second target sub-application in a preset state pool; The status parameter update module is used to parse the data communication instruction, obtain the transmission parameters carried, and update the status parameters corresponding to the second target sub-application based on the transmission parameters.

7. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the one-way data communication method of the micro-front end as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the one-way data communication method of the micro-frontend as described in any one of claims 1 to 5.

Images