CN118394548B - A micro-frontend cross-application information sharing method and micro-frontend architecture system - Google Patents

Abstract

The application provides a micro-front-end cross-application information sharing method and a micro-front-end architecture, which are related to monitoring registration through a decoupling base module. The communication of subsequent data is triggered by determining whether the observer pool is zero. And when the target value changes, the change value is only transmitted to the corresponding sub-application and the base module in the target value issuing relation pool by utilizing the target value issuing relation pool. And a more flexible data communication mode is provided while the efficiency of data transmission is ensured.

Description

A micro-frontend cross-application information sharing method and micro-frontend architecture system

Technical Field

The present application relates to micro-frontend technology, and more specifically, to a micro-frontend cross-application information sharing method and a micro-frontend architecture system.

Background Art

As websites and web apps become more and more complex, microservices, as a technical paradigm widely used on the server side, have been widely extended to the front-end field, namely micro-frontends. In the implementation of micro-frontends, micro-application containerization solutions often use specialized micro-frontend frameworks, such as single-spa, qiankun, etc., to manage and schedule the lifecycle of multiple micro-applications.

In some complex application scenarios, such as scenarios with main-sub-applications or cross-sub-applications, it is often necessary to ensure the fast and accurate transmission and distribution of data status between different sub-applications.

In the existing technology, it is often necessary to use the monitoring mechanism of the micro front-end to achieve this. For the above scenarios, sub-applications are usually embedded in the base application, and in the specific data status transmission process, the information transmission between sub-applications needs to be based on the situation and needs of the base application. That is, for scenarios such as master-sub-application and cross-sub-application, the transmission of information has a strong coupling relationship with the base application, resulting in low efficiency of its processing process.

Summary of the invention

The purpose of this application is to provide a micro-frontend cross-application information sharing method and a micro-frontend architecture system, which are used to improve the efficiency of data communication across application scenarios.

In order to achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

In a first aspect, an embodiment of the present application provides a micro-frontend cross-application information sharing method, the method is applied to a micro-frontend architecture system, the micro-frontend architecture system includes: a data center, a base module and multiple sub-applications, the method includes:

The event center in the data center confirms whether there is an observer in the observer pool; the observer is registered and generated by the base module or any one of the sub-applications;

If the observer exists, the target value is monitored through the global monitoring event;

If the target value changes, the target value change value is sent to the corresponding target sub-application or base module according to the target value sending relationship pool.

Optionally, before the step of the event center in the data center confirming whether there is an observer in the observer pool, the step further includes:

The event center receives a binding request sent by the base module or any sub-application;

The event center establishes a corresponding observer in the observer pool for the corresponding base module or any sub-application according to the binding request;

The event center determines whether the global monitoring event has been established;

If not, the event center establishes the global listening event.

Optionally, the step of monitoring events for the target value includes:

The event center receives an update data status message of a registered sub-application; the update data status message includes the target value and specified identification information; the specified identification information is the identification information of the sub-application or base module that can obtain the changed value when the target value changes;

The event center maintains the target value in a global state pool;

The event center maintains the designated identification information corresponding to the target value through a filter to establish a target value delivery relationship pool;

The data center monitors events of the target value in the global state pool.

Optionally, if the target value changes, the step of sending the change value of the target value to the corresponding target sub-application according to the target value distribution relationship pool includes:

When the event center monitors a change in the target value, it obtains a change value of the target value;

The event center sends the target value to the relationship pool maintained by the filter to confirm the specified identification information corresponding to the change value;

The event center sends the change value to the sub-application and/or the base module corresponding to the designated identification information.

Optionally, it also includes:

The data center receives a data acquisition message sent by any sub-application or the base module; the data acquisition message includes an acquisition instruction of the target value;

The data center sends the target value to the sub-application base module.

Optionally, it also includes:

When the global monitoring event is destroyed, the event center deletes all corresponding observers;

When any sub-application is destroyed, the event center deletes the corresponding observer in the observer pool.

In a second aspect, an embodiment of the present application provides a micro front-end architecture system, the micro front-end architecture system comprising: a data center, a base module and a plurality of sub-applications;

The event center in the data center is used to confirm whether there is an observer in the observer pool; the observer is registered and generated by the base module or any one of the sub-applications; if the observer exists, the target value is monitored through the global monitoring event; if the target value changes, the change value of the target value is sent to the corresponding target sub-application or base module through the relationship pool according to the target value.

In a third aspect, an embodiment of the present application provides an electronic device, including:

A memory for storing one or more programs;

processor;

When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method as described in any one of the above-mentioned first aspects.

In a fifth aspect, an embodiment of the present application provides a program product, which, when executed by a processor, implements a method as described in any one of the above-mentioned first aspects.

Compared with the prior art, the micro-frontend cross-application information sharing method and micro-frontend architecture system provided by the embodiment of the present application do not restrict whether the base module initiates the monitoring registration. The communication of subsequent data is triggered only by judging whether the observer pool is zero. Furthermore, due to the use of the target value distribution relationship pool, when the target value changes, the changed value is only transmitted to the corresponding sub-application and base module. While ensuring the efficiency of data transmission, a more flexible data communication method is provided.

In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

FIG1 is a schematic diagram of a scenario of cross-sub-application data interaction;

FIG2 is a schematic diagram of another scenario of cross-sub-application data interaction;

FIG3 is a schematic diagram of a micro-application architecture;

FIG4 is a schematic diagram of a micro-frontend architecture system provided by an embodiment of the present invention;

FIG5 is a schematic diagram of a flow chart of a micro-frontend cross-application information sharing method provided by an embodiment of the present invention;

FIG6 is a schematic diagram of a flow chart of another micro-frontend cross-application information sharing method provided by an embodiment of the present invention;

FIG7 is a schematic diagram of another micro-frontend architecture system provided by an embodiment of the present invention;

FIG8 is a schematic diagram of a flow chart of another micro-frontend cross-application information sharing method provided by an embodiment of the present invention;

FIG9 is a schematic diagram of another micro-frontend architecture system provided by an embodiment of the present invention;

FIG. 10 is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

Figure 1 is a schematic diagram of a scenario of cross-sub-application data interaction, referring to Figure 1, where sub-application-1 is embedded in the base application. When the data state of sub-application-1 changes, it is necessary to trigger the information change of a specific page of sub-application-2.

In another possible scenario, FIG2 is a schematic diagram of another scenario of cross-sub-application data interaction. Referring to FIG2, the page of sub-application-3 nests sub-application-4. When the data state of sub-application-4 changes, the change of sub-application-3 is triggered. Then, sub-application-4 quickly displays and hides block C in sub-application-4 according to the change of sub-application-3 and its own change.

Obviously, referring to the two examples above, for scenarios where the micro-frontend involves multiple sub-applications, there is a need for cross-application data communication between different sub-applications. The following uses the more mainstream qiankun architecture in the micro-application containerization solution as an example to explain the current cross-application data communication solution.

Specifically, Figure 3 is a schematic diagram of a micro-application architecture. Referring to Figure 3, the architecture includes a base module corresponding to "Micro-Base", a sub-application-1 corresponding to "Micro-APP", a sub-application-2 corresponding to "Micro-APP", a global state pool and an event center.

For the Qiankun architecture, it usually uses "initGlobalState" to define the global state. After the method is executed, it will feedback a "MicroAppStateActions instance", which contains three parts:

1. "onGlobalStateChange": Set the global state pool (GlobalState) - When setting a new target value, the architecture will perform a "shallow check" internally. If the global state pool is found to have changed, a notification will be triggered to all observer functions in the event center, such as observer S, observer A, observer B, etc. as shown in Figure 3.

2. "setGlobalState": Register an observer function - respond to changes in the global state pool. When the global state pool changes, the observer function is triggered.

3. "offGlobalStateChange": cancel the observer function - the instance no longer responds to changes in the global state pool.

The following is an example of FIG3 showing the cross-sub-application data communication process:

Step 1. The base module registers and binds the monitoring function "initGlobalState";

Step 2: The base module sets up observer S, and the event center maintains the corresponding observer S;

Step 3, sub-application 1 and sub-application 2 use "onGlobalStateChange" to bind the monitoring function established by the base module, and set observer A and observer B respectively; then the event center maintains the corresponding observer A and observer B;

Step 4: When the sub-application or base module issues an update instruction for data, send "action" to update the data in the global state pool through "setGlobalState";

Step 5: When the global state pool changes, each sub-application or base module uses the observer of the event center to return the updated data to its own sub-application or base module.

Among them, for the base module, sub-application-1 and sub-application-2, they respectively use "onGlobalStateChange" to monitor the data changes in the global state pool, and then obtain updated data through observer S, observer A and observer B.

Referring to the example shown in FIG3 and its corresponding cross-application data communication solution, it can be found that:

1. In the prior art, for the monitoring function of the global state pool, the process of registering the monitoring function must first be initiated based on the base module. For applications embedded in the third-party base, the sub-application needs to make event delivery adjustments according to the requirements of the base. Therefore, in the prior art, cross-application data communication has a strong coupling relationship with the base module, resulting in insufficient flexibility in data communication.

Second, when an application issues an update command, all observers in the event center will receive the updated data. However, in actual application scenarios, the updated data has no effect or meaning for some applications, which results in inefficient data communication and occupies communication resources.

3. In the existing technical solutions, each sub-application or base module needs to passively obtain updated data by listening and waiting. It is necessary to make corresponding logical conversions for the return value of GlobalState in the onGlobalStateChange callback, and then dump it to the vuex/redux of the corresponding sub-application, and then combine the state management mechanism (vuex/redux) inside the sub-application to perform the corresponding display and hiding logic.

In order to solve the problem in the above technical solution that the monitoring based on the global state pool can only be initiated through the base module, resulting in poor flexibility.

The existing technology also proposes a mechanism to improve the freedom of interaction by using communication classes. The core idea is to use different communication classes to split the original global state pool into multiple pools, so that different applications can subscribe to different communication classes to conduct cross-application data communication relatively independently and freely.

However, the above method still has problems:

First, its communication mechanism is to build communication classes in different namespaces to split the global state pool. In essence, it is an event-driven mechanism. When the application scenario is more complex, once the event naming is repeated, it will cause interference and errors in events in different applications.

Second, in order to ensure that applications can be constrained in the same communication class, "EventHub.emit" and "EventHub.on" are usually used to match event monitoring, that is, when an application initiates an "EventHub.emit", each other application belonging to the communication class must initiate a matching "EventHub .on" to ensure the effective transmission of updated data. However, this method means that each data update corresponds to multiple "EventHub.emit" initiations in a communication class, and the communication efficiency is low.

3. Each communication class must correspond to different event listeners, and the distribution and subscription of events are asynchronous. For complex scenarios, the management complexity of multiple events is high. Multiple communication classes correspond to the complex dependencies of multiple applications under the micro-application architecture, which further leads to unclear relationships between applications and events. And when there are a large number of event listeners and the communication processes triggered by them, performance problems will arise. It can be imagined that this mechanism will have unnecessary impact on the implementation cost, troubleshooting, and computing power requirements of the entire solution.

4. When the application is destroyed, the event will not be removed automatically. Each event may be bound to multiple communication classes, and you need to manually call the relevant removal event to remove it, otherwise it will cause memory overflow.

5. Since there is no global state pool, data is stored in the pool corresponding to a specific communication class. When data acquisition is needed, the threshold for data acquisition is raised invisibly, and the efficiency of data circulation is reduced.

In order to solve the problems caused by the above-mentioned prior art, an embodiment of the present invention provides a different implementation mechanism: by modifying the monitoring mechanism of the micro front end, it is freed from the constraints of the base module host and can be flexibly used under different base modules.

Optionally, FIG4 is a schematic diagram of a micro-frontend architecture system provided by an embodiment of the present invention. Referring to FIG4, the micro-frontend architecture system in this implementation method builds a new "data center", which includes: an event center and a global state pool. All data interactions and operations of sub-applications and base modules are responded to through the data center.

Continuing to refer to FIG. 4 , this example is illustrated with one base module and two sub-applications, namely, sub-application-1 and sub-application-2.

Based on FIG. 4 , FIG. 5 is a flow chart of a micro-frontend cross-application information sharing method provided by an embodiment of the present invention. Referring to FIG. 5 , the method includes:

Step 100: The event center in the data center confirms whether there is an observer in the observer pool.

Among them, the observer is registered and generated by the base module or any sub-application.

Step 101: If an observer exists, the target value is monitored through a global monitoring event.

Specifically, when there is an observer, the sub-application corresponding to the observer monitors the target value through the observer. For example, in the sub-application-2 shown in FIG4 , if there is an observer in the data center, and the observer is observer B, then at this time, sub-application-2 monitors the event of the target value in the global state pool through observer B.

Step 102: If the target value changes, the target value change value is sent to the corresponding target sub-application and/or base module according to the target value distribution relationship pool.

Specifically, for this solution, a target value sending relationship pool can be maintained in the event center, and the target value sending relationship pool is used to indicate the sub-application or base module corresponding to a specific target value. That is, in this solution, by defining which sub-applications or base modules a specific target value needs to be sent to, the change value of the target value can be sent only to the sub-applications and base modules with corresponding requirements, thereby improving the efficiency of data communication.

The micro-frontend cross-application information sharing method provided by the embodiment of the present invention does not restrict whether the base module initiates the monitoring registration. The communication of subsequent data is triggered only by judging whether the observer pool is zero. Furthermore, since the target value is sent to the relationship pool, when the target value changes, the changed value is only transmitted to the corresponding sub-application and base module. While ensuring the efficiency of data transmission, a more flexible data communication method is provided.

At the same time, because it avoids splitting the global state pool using different communication classes, its implementation cost is lower and the complexity of solution maintenance is lower than the solution of using communication classes to communicate data in different namespaces.

Optionally, the data center can be implemented in the form of an npm installation package. Each sub-application and base module can be used by loading the npm installation package. The data center can be installed and used as flexibly as a component.

Optionally, since a core idea provided by an embodiment of the present invention is to separate the initialization and establishment of observers and global listening events from the condition that they must be initiated by the base module, a possible implementation method is provided below to illustrate how to construct observers and global listening events. Specifically, based on FIG5, FIG6 is a flow chart of another micro-frontend cross-application information sharing method provided by an embodiment of the present invention. Referring to FIG6, before step 100, it also includes:

Step 103: The event center receives a binding request sent by the base module or any sub-application.

Specifically, the binding request can be initiated by the base module or sub-application through "onGlobalStateChange", but the difference between "onGlobalStateChange" and the prior art is that the binding request initiated by it also contains identification information for characterizing the base module or sub-application, so that in the subsequent process of sending the target value, the identification information can be used to achieve targeted information sending.

In addition, in this solution, both the base module and the sub-application can directly initiate the process of establishing the observer. Unlike the existing technology, the base module does not need to initiate the process of registering the monitoring function through "initGlobalState", such as initiating registration and monitoring tasks, establishing global monitoring events, defining the global state pool, etc., thereby achieving cross-application data communication and decoupling from the base module.

Step 104: The event center establishes a corresponding observer in the observer pool for the corresponding base module or any sub-application according to the binding request.

Step 105: The event center determines whether the global monitoring event has been established.

Specifically, when there is an observer in the observer pool, that is, when step 104 has completed the establishment of the observer, it is necessary to confirm whether the global listening event in the data center has completed initialization, that is, whether it has been established. If not established, execute step 106. If established, based on the observer established in steps 103 and 104, the existing global listening event can be used to perform the relevant operations of target value monitoring and change value distribution based on step 100 and subsequent steps shown in Figure 5 above.

Step 106: The event center establishes a global monitoring event.

Specifically, if the global listening event is not established, for example, when the first observer is established, or the global listening event is not initialized, step 106 needs to be executed.

It should be noted that, referring to FIG. 6 , after the establishment of the global listening event is completed in step 106, the sub-application may be destroyed, the global listening event may be destroyed, and the observer may be deleted. Therefore, when monitoring the target value, it is first necessary to determine whether there is an observer in the observer pool, that is, the above step 100. If there is no observer in the observer pool at the current moment, it is necessary to return to step 106.

Specifically, based on FIG4, FIG7 is another schematic diagram of a micro-frontend architecture system provided by an embodiment of the present invention, which provides a specific implementation method combined with the "MicroAppStateActions" instance relative to FIG4. Compared with the prior art shown in FIG3, it can be found in combination with FIG7 that the base module in the embodiment of the present invention abandons "initGlobalState". For the base module or any sub-application, it only needs to establish an observer through "onGlobalStateChange".

Then, the event center executes the original "initGlobalState" logic, that is, completes the registration and monitoring tasks, defines the global state, and establishes global monitoring events. Therefore, for the third-party base module, this solution does not need to adapt the base module to realize the registration and initiation of the corresponding monitoring solution. In this solution, since the third-party base does not bear the above-mentioned "initGlobalState" logic, it and other sub-applications complete the establishment of observers through "onGlobalStateChange", thereby improving the applicability of this solution on different third-party base modules.

Specifically, referring to FIG. 7 , the base module establishes observer S in the event center through “onGlobalStateChange”; similarly, the sub-application-1 establishes observer A in the event center through “onGlobalStateChange”; and the sub-application-2 establishes observer B in the event center through “onGlobalStateChange”.

Optionally, based on FIG. 5 , FIG. 8 is a flow chart of another micro-frontend cross-application information sharing method provided by an embodiment of the present invention. Referring to FIG. 8 , step 101 includes:

Step 101 - 1 : The event center receives an update data status message of a registered sub-application.

The registered sub-application refers to a sub-application that has established an observer; the updated data status message includes a target value and specified identification information; the specified identification information is the identification information of the sub-application or base module that can obtain the changed value when the target value changes. Optionally, the registered sub-application can also be a base module.

Step 101-2: The event center maintains the target value in the global state pool.

Step 101 - 3 : The event center maintains the designated identification information corresponding to the target value through the filter to establish a target value delivery relationship pool.

Specifically, the target value delivery relationship pool is used to indicate which sub-applications and/or base modules the changed value can be shared with when a specific target value changes.

Step 101-4: The data center monitors events of the target value in the global state pool.

Continuing to refer to FIG. 8 , step 102 specifically includes:

Step 102-1: When the event center monitors that the target value changes, the change value of the target value is obtained.

Step 102-2: The event center sends the target value maintained by the filter to the relationship pool to confirm the designated identification information corresponding to the change value.

Optionally, if the target value is sent to the relationship pool and a specific target value does not specify clear identification information, the event center can send the change value to all base modules and sub-applications corresponding to the identification information in the form of broadcast.

Step 102-3: The event center sends the change value to the sub-application and/or base module corresponding to the specified identification information.

Specifically, referring to Figure 7, taking sub-application-1 as an example, after sub-application-1 completes the establishment of observer A through "onGlobalStateChange", it can initiate a data status update message to the data center based on "SetGlobalState", which may include: target value and specified identification information. For example, the target value is "A=1", and the specified identification information is the identification information "002" of sub-application-2. Corresponding to the previous step 101-2, the event center in the data center will maintain the specified identification information corresponding to the target value through a filter. And the data center monitors events for the target value that has been maintained in the global state pool. Specifically, the above event monitoring can be implemented using the observer in the event center.

Optionally, referring to the foregoing, the target value sending relationship pool can obtain the correspondence between the observer and the identification information through "onGlobalStateChange", and then obtain the correspondence between the target value and the specified identification information based on "SetGlobalState". Thus, a complete correspondence of "observer-specified identification information-target value" is formed, and its function is: when A changes, the filter in the event center first determines which sub-applications or base modules the change of the target value needs to be returned to. In this example, since the target value "A=1" corresponds to the specified identification information "002", at this time, when the target value changes, the filter determines that the sub-application-2 in the target value sending relationship pool has a corresponding relationship, and then the observer B corresponding to the sub-application-2 will obtain the change value from the global state pool and return the change value, that is, update the state.

It should be noted that the above only takes the identification information of sub-application-2 and the target value "A=1" as an example of having a specified relationship. Obviously, it can also have a similar specified relationship with other sub-applications or base modules, so that when the target value changes, the changed value is sent to the target value relationship pool and flexibly returned to the corresponding one or more sub-applications, the combination of sub-applications and base modules, or only the base module.

In addition, it should be noted that in the examples shown in Figures 5 and 8 above, when it is determined in step 100 that there is no observer in the observer pool, the mechanism shown in Figure 6 can be used to return to step 106 to establish a "global listening event".

In summary, for the embodiment of the present invention, since the data status message is updated by using "SetGlobalState" feedback in each sub-application, the specified identification information is fed back while clarifying the target value. Thus, the target value in the global state pool is flexibly associated with all or part of the sub-applications and base modules. When the target value changes, the data interaction can be global or local. While ensuring the efficiency of data communication, the flexibility of data communication is improved.

Optionally, for the prior art, whether it is a cross-application data communication scheme based on data broadcasting in the global state initiated by the base module, or splitting the global state pool to perform data communication in a communication class. Its data communication method is passive, that is, only when the data changes, the application passively obtains the change value of the data by listening. However, in the actual scenario of micro-applications, for some applications, for certain data in the global state pool, if the data can be actively obtained, the efficiency and flexibility of data communication can be improved. Below, an embodiment of the present invention provides a possible implementation method to achieve flexible acquisition of data in the global state pool. Specifically, the method includes:

The data center receives a data acquisition message sent by any sub-application or base module.

Specifically, the data acquisition message includes an acquisition instruction of the target value.

In turn, the data center sends the target value to the sub-application or base module.

Specifically, based on Figure 7, Figure 9 is another schematic diagram of a micro-frontend architecture system provided by an embodiment of the present invention. Referring to Figure 9, relative to Figure 7, the embodiment of the present invention introduces a new sub-application-3, which can have similar functions to sub-application-1 or sub-application-2, such as using "onGlobalStateChange" to establish an observer to monitor data changes; using "SetGlobalState" to specify target values and specify identification information, etc.

In the embodiment of the present invention, the sub-application-3 can also use "GetGlobalState" to implement the data acquisition function, that is, use "GetGlobalState" to send a data acquisition message to the global state pool. Correspondingly, the global state pool can expose the data to the sub-application-3 through the "expose Getter" method.

It should be noted that the sub-application-3 shown in Figure 9 is a registered sub-application that has completed the establishment of relevant observers. In another possible implementation, a sub-application can also directly obtain the data maintained by the "exposed Getter" method in the global state pool through the above data acquisition message without performing the observer-related establishment process.

In addition, compared with the method of splitting the global state pool by using the communication class, even if the data can be shared, it can only be realized in the sub-data pool corresponding to the same communication class, and it is impossible to actively obtain data globally. In the above example of this application, the data of the global state pool can be obtained by any sub-application or base module, and the data communication efficiency is significantly improved.

In another possible implementation, the observers maintained in the data center observer pool in the above example can be deleted when the corresponding sub-application is destroyed. This ensures a flexible and accurate correspondence between observers and sub-applications and base modules. Specifically, the following situations exist:

Case 1: When the global monitoring event is destroyed, the event center deletes all corresponding observers.

Specifically, each time the target value corresponding to the global listening event is issued, a "hasEventListener" judgment can be performed to confirm whether the global listening event is destroyed. In addition, as mentioned above, when the observer pool is empty and no new observer is established, the global listening event can also be destroyed. At this time, since there is no observer, it does not involve the deletion of related observers.

Case 2: When a specific sub-application is destroyed, the event center deletes the observer corresponding to the sub-application.

Specifically, when the sub-application is destroyed, the corresponding observer state is "inactive state", and the event center can delete the observer in the "inactive state" based on the confirmed observer state.

In this solution, there is no need to set up different communication classes, but data changes are monitored based on a global monitoring event. This avoids the need to manually remove the corresponding event monitoring for different communication classes when the application is destroyed in the event-driven data communication method, ensuring the communication efficiency of data communication and reducing the implementation cost.

Optionally, referring to the above embodiment of the present invention, a micro-front-end architecture system is also provided, referring to the above Figures 4, 7 and 9, the micro-front-end architecture system includes: a data center, a base module and multiple sub-applications.

The event center in the data center is used to confirm whether there is an observer in the observer pool; the observer is registered and generated by the base module or any sub-application; if there is an observer, the target value is monitored through the global monitoring event; if the target value changes, the target value change value is sent to the corresponding target sub-application or base module according to the target value distribution relationship pool.

The micro-frontend architecture system can be used to execute each process step in the above example to achieve the corresponding technical effects.

The embodiment of the present invention further provides an electronic device, which can execute all the steps of the above examples of the embodiment of the present invention to achieve the corresponding technical effects. Specifically, FIG10 is a schematic diagram of the structure of an electronic device provided by the embodiment of the present invention. Referring to FIG10, the electronic device 20 includes: a memory 201, a processor 200;

Memory 201, used to store one or more programs;

Processor 200;

When one or more programs are executed by the processor, when the electronic device 20 is used to execute the steps shown in the above-mentioned method examples, it can achieve each step and corresponding technical effects.

In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and a part of the module, program segment or code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and/or flowchart, and the combination of boxes in the block diagram and/or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product. The program product is stored in a computer-readable storage medium, including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

It will be apparent to those skilled in the art that the present application is not limited to the details of the exemplary embodiments described above, and that the present application can be implemented in other specific forms without departing from the spirit or essential features of the present application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the present application is defined by the appended claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims be included in the present application. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

Claims (9)

1. The micro-front-end cross-application information sharing method is characterized by being applied to a micro-front-end architecture system, and the micro-front-end architecture system comprises: a data center, a base module, and a plurality of sub-applications, the method comprising:

An event center in the data center confirms whether an observer exists in the observer pool; the observer is generated by the base module or any one of the sub-applications registration;

If the observer exists, the event center receives an update data status message of the registered sub-application; the update data status message contains a target value and specified identification information; the appointed identification information is identification information of a sub-application or a base module which can obtain the change value when the target value changes;

The event center maintains the target value in a global state pool;

the event center maintains the appointed identification information corresponding to the target value through a filter so as to establish a target value issuing relation pool;

The data center monitors the target value in the global state pool for events;

If the target value changes, sending a change value of the target value to a corresponding target sub-application or base module according to the target value issuing relation pool; the target value issuing relation pool is used for indicating the sub-application or the base module corresponding to the target value.

2. The method of claim 1, further comprising, prior to the step of the event center in the data center confirming whether an observer exists in the observer pool:

the event center receives a binding request sent by a base module or any one of the sub-applications;

the event center establishes a corresponding observer in the observer pool for a corresponding base module or any sub-application according to the binding request;

the event center judges whether the global monitoring event is established or not;

If not, the event center establishes the global monitoring event.

3. The method of claim 1, wherein the step of sending the changed value of the target value to the corresponding target sub-application according to the target value issuing relationship pool if the target value is changed comprises:

When the event center monitors that the target value changes, a change value of the target value is obtained;

The event center issues a relation pool through the target value maintained by the filter, and confirms the appointed identification information corresponding to the change value;

and the event center sends the change value to the sub-application and/or the base module corresponding to the appointed identification information.

4. The method as recited in claim 1, further comprising:

The data center receives a data acquisition message sent by any sub-application or the base module; the data acquisition message contains an acquisition indication of the target value;

The data center applies the target value sent by the base module to the sub-application.

5. The method as recited in claim 1, further comprising:

when the global monitoring event is destroyed, the event center deletes all corresponding observers;

when any sub-application is destroyed, the event center deletes the corresponding observer in the observer pool.

6. A micro front end architecture system, the micro front end architecture system comprising: the system comprises a data center, a base module and a plurality of sub-applications;

An event center in the data center for confirming whether an observer exists in the observer pool; the observer is generated by the base module or any one of the sub-applications registration; if the observer exists, the event center receives an update data status message of the registered sub-application; the update data status message contains a target value and specified identification information; the appointed identification information is identification information of a sub-application or a base module which can obtain the change value when the target value changes; the event center maintains the target value in a global state pool; the event center maintains the appointed identification information corresponding to the target value through a filter so as to establish a target value issuing relation pool; the data center monitors the target value in the global state pool for events; if the target value changes, sending a change value of the target value to a corresponding target sub-application or base module according to a target value issuing relation pool; the target value issuing relation pool is used for indicating the sub-application or the base module corresponding to the target value.

7. An electronic device, comprising:

A memory for storing one or more programs;

A processor;

the method of any of claims 1-5 is implemented when the one or more programs are executed by the processor.

8. A computer readable storage medium, on which a computer program is stored, which computer program, when being executed by a processor, implements the method according to any of claims 1-5.

9. A program product, characterized in that it implements the method according to any of claims 1-5 when being executed by a processor.