Method and system for multi-tab synchronization in conjunction with page visibility for broadcast channel

Abstract

The application discloses a multi-tab synchronization method and system cooperating with a broadcast channel and page visibility. The method detects the feature method and attribute of a target instance to identify the instance type, and rewrites the corresponding atomic operation method; creates a broadcast channel instance as a synchronization channel across tabs; when the atomic operation method is called, the synchronization enable item and synchronization mode item are parsed from the configuration object of the last parameter, the method name and parameters are encapsulated as a synchronization message, and are sent according to the anti-shake, throttling, immediate or visibility strategy. When the receiving tab uses the visibility strategy, the page is visible, the application state is changed, the page is invisible, the synchronization message is stored in the to-be-processed queue, and is processed in turn when the page becomes visible. Thus, the unified adaptation of various state management libraries and event buses is realized, the coupling degree of synchronization logic and business logic is reduced, and the invalid processing of high-frequency communication and invisible pages is reduced.

Description

Technical Field

[0001] This invention relates to the field of data communication and state management technology for web applications, specifically to a multi-tab synchronization method and system that coordinates broadcast channels and page visibility.

[0002] This invention is applicable to state changes or event message synchronization between state management library instances and event bus instances in a browser multi-tab environment. Background Technology

[0003] With the development of single-page applications and front-end state management technologies, opening multiple tabs of the same web application simultaneously in the same browser has become a common practice. Different tabs maintain their own runtime context and memory state. When the state data, configuration data, or event responses in one tab change, other tabs usually cannot directly perceive the change and need to rely on the cross-context communication capabilities provided by the browser to pass the corresponding information.

[0004] Existing cross-tab synchronization solutions typically send state change messages via broadcast channels, stored events, or shared worker threads. While broadcast channels can establish message transmission links between tabs from the same origin, developers generally need to write separate message encapsulation, sending, and receiving logic for each specific state management library or event bus, and set additional synchronization conditions at each business call location. The atomic operation methods and parameter formats provided by different instances vary, making synchronization configurations easily scattered throughout the business code, increasing the complexity of adaptation and maintenance.

[0005] Furthermore, existing solutions typically broadcast changes immediately after a state change, with the receiving tab applying the received state change instantly. For scenarios involving continuous input, dragging, or other high-frequency calls, this approach can generate a large number of synchronization messages in a short period. For tabs currently in an invisible state, immediately performing all state changes also consumes computational resources. Simply reducing message frequency by delaying transmission is insufficient to simultaneously meet the different needs of immediate synchronization of critical states and delayed processing of non-critical states.

[0006] Therefore, the existing technology has at least the following limitations: On the one hand, the atomic operation interfaces of different state management libraries and event buses are different, and cross-tab synchronization logic is difficult to implement through a unified configuration entry point, which can easily lead to coupling between adaptation logic and business logic; on the other hand, the message sending frequency and receiving processing timing lack a control mechanism that matches the call type, synchronization requirements and page visibility, making it difficult to balance the consistency of multi-tab state and communication processing performance. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a multi-tab synchronization method and system that coordinates broadcast channels and page visibility, so as to solve the problem of lack of unified adaptation and configuration entry for different state management libraries and event buses, and to solve the problem that it is difficult to control the sending frequency and receiving and processing timing of cross-tab synchronization messages according to synchronization requirements.

[0008] To address the aforementioned technical problems, this invention provides a multi-tab synchronization method that coordinates broadcast channels and page visibility, comprising: detecting the characteristic methods and attributes of a target instance to identify the instance type, and rewriting the atomic operation methods of the target instance according to the instance type while maintaining the original calling format and operation mode, wherein the atomic operation methods are methods in the target instance used to complete state changes or event sending; creating a broadcast channel instance with a preset name as a cross-tab synchronization channel; when the atomic operation method is called, parsing the configuration object in the last parameter of this call to obtain a synchronization enable item indicating whether cross-tab synchronization is enabled, and a synchronization mode item indicating debouncing, throttling, immediate, or visibility processing strategies; When the synchronization enable option is enabled, the method name and parameters of this call are encapsulated into a synchronization message and sent through the synchronization channel according to the debouncing, throttling, immediate, or visibility strategy corresponding to the synchronization mode option. Upon receiving a tab, for the synchronization message using the visibility strategy, the state change carried by the synchronization message is applied when the page is visible, and stored in a pending queue when the page is invisible. Similar non-cumulative state changes in the pending queue are overwritten and merged to retain the latest final state. When the page visibility is detected to change from invisible to visible, the merged synchronization messages in the pending queue are processed sequentially. When applying the state change, the synchronization enable option of the corresponding atomic operation method being called is explicitly configured to be disabled to prevent secondary broadcasting.

[0009] Furthermore, the method and attributes of detecting the target instance are used to identify the instance type, and the atomic operation methods of the target instance are rewritten according to the instance type while maintaining the original calling format and operation method. The atomic operation methods are methods in the target instance used to complete state changes or event sending, including: receiving the target instance and the initial configuration parameters passed in with the target instance; merging the initial configuration parameters into a preset default configuration when the initial configuration parameters are of object type; detecting whether the target instance has a $onAction method, a $patch method, and a $id attribute; determining that the instance type is the Pinia state management library when all of them are present; and detecting whether the target instance has a commit method. The system checks whether the target instance has the `_mutations` and `_actions` properties. If both are present, the instance type is determined to be a Vue state management library. It also checks whether the target instance has the `$emit` and `$on` methods. If both are present, the instance type is determined to be a Vue event bus. Furthermore, it checks whether the target instance has the `emit` method, the `on` method, and the `all` property used to record the correspondence between event names and listener function sets. If all are present, the instance type is determined to be a Mitt event emitter. Based on the determined instance type, the system calls the adaptation logic corresponding to the instance type, rewrites the atomic operation methods of the target instance, outputs warning messages to target instances whose instance type is not determined, and returns the target instance.

[0010] Furthermore, the step of invoking the adaptation logic corresponding to the instance type obtained by the determination, and rewriting the atomic operation method of the target instance, includes: when the instance type is the Pinia state management library, listening for action execution through the $onAction method of the target instance, and using the crossAction method as the sole entry point for cross-tab operations; when the instance type is the Vuex state management library, rewriting the commit method of the target instance; when the instance type is the Vue event bus, rewriting the $emit method of the target instance; when the instance type is the Mitt event emitter, rewriting the emit method of the target instance; after rewriting the atomic operation method, maintaining the original calling form of the atomic operation method, and triggering cross-tab synchronization after the atomic operation method is executed.

[0011] Further, when the atomic operation method is invoked, parsing the configuration object in the last parameter of this invocation to obtain a synchronization enable item indicating whether cross-tab synchronization is enabled, and a synchronization mode item indicating debouncing, throttling, immediate, or visibility processing strategies, includes: determining whether the last parameter of this invocation is an object type; if the last parameter is an object type, using the last parameter as the configuration object; reading the boolean synchronization enable item from the configuration object, the synchronization enable item indicating whether cross-tab synchronization is enabled; reading the enumerated synchronization mode item from the configuration object, the synchronization mode item being one of a debouncing strategy, a throttling strategy, an immediate strategy, and a visibility strategy; reading the numeric time interval item from the configuration object, the time interval item indicating the time interval between the debouncing strategy and the throttling strategy; and supplementing any configuration items not given in the configuration object with the corresponding configuration items in the preset default configuration to obtain the synchronization enable item and the synchronization mode item that are effective in this invocation.

[0012] Further, when the synchronization enable item is enabled, the method name and parameters of this call are encapsulated into a synchronization message and sent through the synchronization channel according to the debouncing, throttling, immediate, or visibility strategy corresponding to the synchronization mode item. This includes: encapsulating the method name, the parameters, the type identifier indicating the category to which the target instance belongs, and the synchronization mode item into the synchronization message, and retrieving serializable metadata for the parameters; when the synchronization mode item is an immediate strategy, placing the synchronization message into a sending queue and sending it immediately through the synchronization channel; when the synchronization mode item is a visibility strategy, sending the synchronization message immediately through the synchronization channel, and determining the processing timing based on page visibility by the receiving tab; when the synchronization mode item is a debouncing strategy, wrapping the sending action with a debouncing function, and sending the last synchronization message after the delay time indicated by the time interval item in the configuration object has expired; when the synchronization mode item is a throttling strategy, wrapping the sending action with a throttling function, and sending the synchronization message only once within the interval indicated by the time interval item.

[0013] Furthermore, when the synchronization mode is a debouncing strategy, wrapping the sending action with a debouncing function and sending the last synchronization message after the delay time indicated by the time interval item in the configuration object expires includes: starting a debouncing timer when the atomic operation method is called, the timing duration of the debouncing timer being taken from the time interval item; when the atomic operation method is called again during the debouncing timer's timing period, resetting the debouncing timer and replacing the cached synchronization message with the synchronization message of this call; when the debouncing timer expires, sending the cached last synchronization message through the synchronization channel and clearing the cached synchronization message.

[0014] Further, when receiving a tab, for the synchronization message using a visibility strategy, the state change carried by the synchronization message is applied when the page is visible, and stored in a waiting queue when the page is invisible. Similar non-cumulative state changes in the waiting queue are overwritten and merged to retain the latest final state. When the page visibility changes from invisible to visible, the merged synchronization messages in the waiting queue are processed sequentially. When applying the state change, the synchronization enable item of the corresponding atomic operation method is explicitly configured to be disabled to prevent secondary broadcasting. This includes: when the receiving tab obtains the synchronization message through the message receiving listener of the synchronization channel and reads the synchronization mode item in the synchronization message; when the read synchronization mode item is a visibility strategy, the current page visibility state of the receiving tab is queried; when the page visibility state is visible, ... The message processor corresponding to the type identifier of the synchronization message is invoked to apply the state change carried by the synchronization message. When the page visibility state is invisible, the synchronization message is stored in the processing queue in the order of receipt, and the same type of non-cumulative state change messages with the same instance and the same method name in the processing queue are overwritten and merged to retain the latest synchronization message. The non-cumulative state change refers to the state change of the state result of the later call that can directly overwrite the state change of the previous call result. The page visibility change event is listened for. When the page visibility change event indicates that the received tab has changed from invisible to visible, all the merged synchronization messages in the processing queue are processed in the order of receipt and the processing queue is cleared. When applying the state change, the synchronization enable item of the corresponding atomic operation method called is explicitly configured to be disabled to prevent secondary broadcasting.

[0015] Further, when the page visibility state is visible, the step of invoking the message processor corresponding to the type identifier of the synchronization message and applying the state change carried by the synchronization message includes: verifying the message format and integrity of the synchronization message and discarding synchronization messages that fail the verification; querying the message processor corresponding to the type identifier of the synchronization message in the message processor registry, wherein the message processor registry is a mapping data structure with the type identifier as the key and the message processor as the value, supporting the dynamic addition and removal of message processors; when the type identifier indicates a change in the state management library, retrieving the method name and the parameter from the synchronization message, passing the parameter to the atomic operation method corresponding to the method name in the target instance and invoking it; when the type identifier indicates an event bus message, retrieving the event name and the parameter from the synchronization message, passing the parameter to the listener function array corresponding to the event name and executing them sequentially; after invoking the atomic operation method or executing the listener function array, obtaining the receiving tab state consistent with the sending tab state.

[0016] Furthermore, the method also includes: before creating the broadcast channel instance, detecting whether the current browser environment supports the broadcast channel interface, and performing the creation if the broadcast channel interface is supported; when a state change call is triggered by the synchronization message, explicitly setting the synchronization enable item to a disabled state in the parameter configuration object, so that the state change call no longer sends the synchronization message through the synchronization channel; the broadcast channel instance does not deliver the synchronization message to the sending tab itself, eliminating the source identifier in the synchronization message; for symmetric data synchronization scenarios requiring consistent states across multiple tabs, the target instance is taken as a state management library instance; for asymmetric state response scenarios where each tab responds differently according to its own state, the target instance is taken as an event bus instance.

[0017] This invention also provides a multi-tab synchronization system that coordinates broadcast channels and page visibility, comprising: an adaptation and identification module, used to detect the characteristic methods and attributes of a target instance to identify the instance type, and rewrite the atomic operation methods of the target instance according to the instance type while maintaining the original calling format and operation mode, wherein the atomic operation methods are methods in the target instance used to complete state changes or event sending; a channel establishment module, used to create a broadcast channel instance with a preset name as a cross-tab synchronization channel; and a configuration parsing module, used to parse the configuration object in the last parameter of the current call when the atomic operation method is called, to obtain a synchronization enable item indicating whether cross-tab synchronization is enabled, and a synchronization mode item indicating debouncing, throttling, immediate or visibility processing strategies; and a channel establishment module, used to parse the configuration object in the last parameter of the current call when the atomic operation method is called, to obtain a synchronization enable item indicating whether cross-tab synchronization is enabled, and a synchronization mode item indicating debouncing, throttling, immediate or visibility processing strategies; and a channel establishment module, used to create a broadcast channel instance with a preset name as a cross-tab synchronization channel ... The sending strategy module is used to encapsulate the method name and parameters of the current call into a synchronization message when the synchronization enable item is enabled, and send it through the synchronization channel according to the debouncing, throttling, immediate, or visibility strategy corresponding to the synchronization mode item. The receiving and processing module is used to, when receiving a tab, apply the state change carried by the synchronization message to the synchronization message using the visibility strategy when the page is visible, store it in a waiting queue when the page is invisible, and overwrite and merge the same non-cumulative state changes in the waiting queue to retain the latest final state; when the page visibility is detected to change from invisible to visible, process the merged synchronization messages in the waiting queue in sequence; when applying the state change, explicitly configure the synchronization enable item of the corresponding atomic operation method being called to be disabled to prevent secondary broadcasting.

[0018] The beneficial effects of this invention are as follows:

[0019] This invention employs a mechanism that identifies instance types based on the characteristics and attributes of target instances and rewrites atomic operation methods according to instance types. This allows different state management libraries and event buses to share configuration parsing, message encapsulation, and broadcast transmission links, thereby reducing the coupling between cross-tab synchronization logic and specific business calls, and reducing the workload of setting adaptation and synchronization code separately for different instances. Furthermore, by parsing the synchronization enable item, synchronization mode item, and time interval item from the last parameter of the atomic operation method and controlling the timing of message sending and receiving according to debouncing, throttling, immediate, or visibility strategies, high-frequency calls can reduce redundant messages through debouncing or throttling strategies, messages requiring timely synchronization can be sent immediately, and invisible tabs can temporarily store synchronization messages using visibility strategies. This maintains multi-tab state synchronization capabilities while reducing communication channel occupancy and invalid processing of invisible pages. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the overall process of the multi-tab status synchronization method of the present invention;

[0022] Figure 2 This is a schematic diagram of the instance type identification and atomic operation method rewriting process of the present invention;

[0023] Figure 3 This is a schematic diagram of the configuration parsing process of the present invention;

[0024] Figure 4 This is a schematic diagram of the multi-strategy synchronous message sending process of the present invention;

[0025] Figure 5 This is a schematic diagram of the page visibility awareness message processing flow of the present invention;

[0026] Figure 6 This is a schematic diagram of the module structure of the multi-tab status synchronization system of the present invention;

[0027] Figure 7 This is a flowchart of the multi-tab synchronization method for coordinating broadcast channels and page visibility according to the present invention. Detailed Implementation

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments are used to illustrate the technical solutions of the present invention, and not to limit the scope of protection of the present invention. Where there is no conflict, the technical features of the various embodiments can be combined with each other.

[0029] In this implementation, the target instance can be a state management library instance or an event bus instance. The state management library instance is used to handle symmetric data synchronization scenarios requiring consistent states across multiple tabs, while the event bus instance is used to handle asymmetric state response scenarios where each tab responds differently based on its own state. The broadcast channel instance can be established using a broadcast channel interface provided by the browser environment (e.g., the BroadcastChannel interface) to transmit serializable synchronization messages between different tabs originating from the same source.

[0030] like Figure 1 As shown, this embodiment provides a multi-tab synchronization method that coordinates broadcast channels and page visibility, including the following steps.

[0031] S1. Detect the characteristic methods and attributes of the target instance to identify the instance type, and rewrite the atomic operation methods of the target instance according to the instance type in a way that maintains the original calling form and the original operation method. The atomic operation methods are the methods in the target instance used to complete state changes or event sending.

[0032] The target instance can be a state management library instance or an event bus instance passed in by the web application. Different instances have different characteristic methods, characteristic attributes, and atomic operation methods. For example, state management library instances typically implement state changes through action invocation, state commit, or state patching, while event bus instances typically trigger listener functions through event emission methods.

[0033] In this embodiment, the atomic operation method refers to the smallest granularity method in the target instance used to complete a single state change or a single event sending. This includes the action methods, state commit methods, and state patching methods of the state management library instance (e.g., the action call method and $patch method of the Pinia state management library, and the commit method of the Vuex state management library), as well as the event sending methods of the event bus instance (e.g., the $emit method of the Vue event bus, and the emit method of the Mitt event emitter). Subsequent steps involving the rewriting of atomic operation methods, configuration parsing, and synchronous message sending are all implemented based on the above methods.

[0034] This step involves forming an instance feature set by reading the methods and attributes exposed by the target instance, and then matching this instance feature set with preset instance type identification conditions. Upon successful matching, the corresponding adaptation logic is invoked to rewrite the atomic operation methods that carry out state change or event sending functions. The rewritten atomic operation methods still receive business parameters according to the original calling format, so that existing business code does not need to change its main calling method for cross-tab synchronization functionality.

[0035] In one implementation, the rewriting process first saves references to the atomic operation methods, then generates wrapper methods to replace them. The wrapper method receives all parameters from the current call, invokes the saved atomic operation method to complete the original operation within the current tab, and determines whether to perform cross-tab synchronization based on the configuration object in the last parameter. Thus, the synchronization control logic is centralized in the adaptation layer, rather than being distributed across various business processing locations.

[0036] S2. Create a broadcast channel instance with a preset name as a synchronization channel across tabs;

[0037] After confirming that the current browser environment supports the broadcast channel interface, a broadcast channel instance is created with a preset name. Tabs opened in the same web application and using the same preset name are thus added to the same logical communication channel and can transmit synchronization messages through the message sending interface and message receiving listener of the broadcast channel instance.

[0038] The preset name can be configured by the caller or a default name provided by the system. To prevent different applications or business modules under the same domain from receiving messages from each other, at least one of the application identifier, business identifier, or version identifier can be added to the preset name. Broadcast channel instances can be closed when no longer in use to release corresponding browser resources.

[0039] S3. When the atomic operation method is called, parse the configuration object in the last parameter of this call to obtain a synchronization enable item for indicating whether cross-tab synchronization is enabled, and a synchronization mode item for indicating debouncing, throttling, immediate or visibility processing strategies.

[0040] The rewritten atomic operation method reads the last parameter from the parameter sequence of this call and determines whether the parameter is an object type that can be processed as a configuration object. If the result is yes, it reads the synchronization enable item and synchronization mode item from the configuration object; if the configuration object is missing the corresponding configuration item, it uses the corresponding value from the preset default configuration to fill in the missing items.

[0041] The synchronization enable option is a boolean value used to determine whether cross-tab synchronization should be triggered for this call. The synchronization mode option is an enumeration type that can represent debouncing, throttling, immediate, or visibility strategies. The configuration object can also include a time interval option, which serves as the delay time for the debouncing strategy or the limiting interval for the throttling strategy. In actual configuration, the synchronization enable option, synchronization mode option, and time interval option can be represented by the fields crossTab, syncMode, and delay, respectively.

[0042] When parsing configuration objects, only predefined configuration fields can be recognized, and other parameters besides the configuration object can continue to be used as business parameters for atomic operation methods. For synchronization mode items that cannot be recognized, the default synchronization mode can be used, or the current cross-tab sending can be stopped and a prompt message can be output.

[0043] S4. When the synchronization enable item is enabled, the method name and parameters of this call are encapsulated into a synchronization message and sent through the synchronization channel according to the debouncing, throttling, immediate or visibility strategy corresponding to the synchronization mode item.

[0044] A synchronization message includes at least a method name, parameters, a type identifier, and a synchronization mode item. The method name is used to locate the atomic operation method to be called or the event to be triggered in the receiving tab. The parameters are used to restore the current state change or event call. The type identifier is identification information indicating the category to which the target instance belongs (e.g., the category code that distinguishes between the state management library and the event bus) and is used to determine the message handler. The synchronization mode item is used to determine the timing of receiving and processing.

[0045] Since data transmitted via broadcast channels needs to meet structured cloning or corresponding serialization requirements, the message encapsulation process can extract serializable metadata from the parameters. For proxy objects, their original data can be read or a data copy without proxy behavior can be formed; for functions, document nodes, and other objects unsuitable for cross-tab transmission, they can be filtered or converted into corresponding identifiable descriptions.

[0046] Debouncing (the debounce mechanism commonly used in this field) is suitable for calls that occur consecutively within a short period of time and only require retaining the final state. Throttling (the throttle mechanism commonly used in this field) is suitable for calls that occur continuously but require limiting the sending frequency. Immediate policy is suitable for state changes that need to be propagated in a timely manner. Visibility policy sends a synchronization message immediately on the sending tab, and the receiving tab determines whether to process it immediately or postpone it based on its own page visibility.

[0047] In one example, the time interval can be set from 50 milliseconds to 5000 milliseconds. For text input calls, the debouncing time can be set from 300 milliseconds to 500 milliseconds; for continuous position update calls, the throttling interval can be set from 50 milliseconds to 200 milliseconds. If the time interval is too small, its effect on reducing redundant messages is relatively limited; if the time interval is too large, it will increase the waiting time for the receiving tab to obtain the final state. The above values ​​are merely examples and do not constitute a limitation on the scope of protection.

[0048] S5. Upon receiving a tab, for the synchronization message employing a visibility strategy, apply the state change carried by the synchronization message when the page is visible, and store it in a pending queue when the page is invisible. Overwrite and merge similar non-cumulative state changes in the pending queue to retain the latest final state. When the page visibility changes from invisible to visible, process the merged synchronization messages in the pending queue sequentially. When applying the state change, explicitly configure the synchronization enable item of the corresponding atomic operation method being called to a disabled state to prevent secondary broadcasting.

[0049] The receiving tab receives synchronization messages through the message receiving listener of the broadcast channel instance. For synchronization messages with an immediate, debouncing, or throttling strategy, the corresponding message handler can be called after the message verification passes; for synchronization messages with a visibility strategy, the visibility status of the current page is further queried.

[0050] When the receiving tab is visible, the message handler corresponding to the type identifier is invoked, and the state change carried by the synchronization message is applied to the receiving tab. When the receiving tab is invisible, synchronization messages are stored in the processing queue in the order they were received, without immediately executing the corresponding state change. After the page becomes visible again, the synchronization messages in the processing queue are processed sequentially.

[0051] Because invisible tabs do not execute state changes using the visibility strategy, the timing of message transmission and state application is separated, thereby reducing real-time computation on invisible pages. The pending queue preserves the message reception order, allowing interdependent state changes to be applied in the order they were sent, reducing the possibility of state inconsistencies due to changes in processing order.

[0052] like Figure 2 As shown, this embodiment, based on embodiment 1, refines the feature method and attributes for detecting target instances to identify instance types, and rewrites the atomic operation method of the target instance according to the instance type, including the following steps.

[0053] S1.1. Receive the target instance and the initial configuration parameters passed in with the target instance, and merge the initial configuration parameters into the preset default configuration when the initial configuration parameters are of object type;

[0054] The initial configuration parameters are used to set instance-level configurations for the target instance. Preset default configurations may include default synchronization enablement, synchronization mode, time interval, and broadcast channel name. When the initial configuration parameter is an object type, the given configuration items override the corresponding items in the preset default configuration; ungiven configuration items continue to use the preset default configuration.

[0055] Instance-level configuration and call-level configuration can form a hierarchical overriding relationship. Specifically, the basic configuration corresponding to the target instance is first obtained through initial configuration parameters, and then the configuration object in the last parameter of the atomic operation method overrides the configuration items involved in this call. Thus, different target instances can share the system's default configuration, while allowing a single call to change the synchronization strategy according to business needs.

[0056] S1.2. Detect whether the target instance has the $onAction method, $patch method and $id attribute. If it has all of them, determine that the instance type is Pinia state management library.

[0057] This step involves accessing the corresponding members of the target instance to determine if the listed methods are callable and to check if the $id attribute exists. If all identification conditions are met, the target instance is registered in the Pinia state management library and assigned a corresponding type identifier.

[0058] In the implementation, the detection process can be completed using secure attribute access methods to avoid interrupting the identification process due to the target instance using proxy objects or accessor attributes. The instance type identification result is used to select the corresponding action listener and cross-tab operation adaptation logic.

[0059] S1.3. Detect whether the target instance has a commit method, a _mutations attribute, and a _actions attribute. If all of them are present, determine that the instance type is a Vuex state management library.

[0060] The code checks whether the `commit` method is callable and whether the `_mutations` and `_actions` attributes exist. If all the identification conditions are met, the target instance is determined to be the Vuex state management library, and the `commit` method is identified as the atomic operation method to be overridden.

[0061] By combining detection methods and internal attributes, the possibility of misclassifying instance types based solely on a single method with the same name can be reduced. For objects with similar method names but that do not meet the complete identification criteria, the corresponding adaptation logic of the Vuex state management library is not executed.

[0062] S1.4. Detect whether the target instance has the $emit method and the $on method. If both are present, determine that the instance type is Vue Event Bus.

[0063] When the corresponding method identification conditions are met, the target instance is determined to be a Vue event bus. The synchronization objects of the event bus do not necessarily have to maintain the same centralized state across all tabs; instead, they can be event messages that each tab responds to based on its own context.

[0064] For an event bus instance, the type identifier can be set to the event bus message type so that the receiving tab selects the event message handler in the message handler registry instead of the state management library change handler.

[0065] S1.5. Detect whether the target instance has the emit method, the on method, and the all attribute used to record the correspondence between event names and the set of listening functions. If all of them are present, determine that the instance type is a Mitt event emitter.

[0066] In addition to detecting the `emit` and `on` methods, this step also checks whether the `all` property is a mapping type. The `all` property stores the correspondence between event names and the set of listener functions. If all the identification conditions are met, the target instance is determined to be a Mitt event emitter.

[0067] In the subsequent receiving and processing process, the array of listening functions can be read from the mapping structure corresponding to the all attribute according to the event name, and executed according to the registration order of the listening functions, so that the receiving tab can process cross-tab events according to its own registered listening relationship.

[0068] S1.6. Based on the determined instance type, call the adaptation logic corresponding to the instance type, rewrite the atomic operation method of the target instance, output a warning message for the target instance whose instance type has not been determined, and return the target instance.

[0069] After the instance type is determined, the corresponding adapter function is selected from the adapter logic set, and the target instance, the merged configuration, and the broadcast channel instance are passed to the adapter function. After the adapter function completes the wrapping of the atomic operation method or the action listener setting, it returns the original target instance.

[0070] For target instances whose instance type cannot be determined, their existing methods are not directly modified to avoid mismatched adaptation logic affecting the original functionality of the target instance. The system can output warning messages that do not contain sensitive business data and still return the target instance, allowing the caller to continue using the original instance or register an extension adapter itself.

[0071] Based on Example 2, this embodiment further refines the process of calling the adaptation logic corresponding to the instance type obtained by the determination and rewriting the atomic operation method of the target instance.

[0072] S1.6.1. When the instance type is Pinia State Management Library, the execution of actions is monitored through the $onAction method of the target instance, and the crossAction method is used as the only entry point for cross-tab operations;

[0073] Action listeners can obtain the action name, call parameters, and callback timing after the action is completed. The `crossAction` method receives the action information to be executed and the configuration object, and directs all operations that need to be synchronized across tabs to this entry point. For local actions not initiated through the `crossAction` method, synchronization can be determined according to the default configuration.

[0074] The `crossAction` method, provided by this invention, serves as the entry point for uniformly receiving cross-tab synchronization action calls. When the business code initiates an action requiring cross-tab synchronization, it passes the action information and configuration object to the `crossAction` method. The `crossAction` method then executes the action and triggers the encapsulation and sending of a synchronization message upon completion. Therefore, all cross-tab synchronization action calls are centrally processed through a single entry point, eliminating the need for synchronization control logic to be distributed across different actions. This signifies that the `crossAction` method is the sole entry point for cross-tab operations.

[0075] Generating a synchronous message only after an action is successfully executed allows the sending tab to complete its local state change first, preventing invalid changes from being sent to other tabs due to local action failure. If the action returns an asynchronous result, synchronization can be triggered after the asynchronous result is successful; if the action encounters an error, local error handling logic is retained and the sending of the corresponding message is stopped.

[0076] S1.6.2. When the instance type is a Vuex state management library, override the commit method of the target instance;

[0077] Before rewriting, the original commit method and its calling context are preserved. The wrapped commit method parses the configuration object in the last parameter and passes the valid business parameters, except for cross-tab configuration, to the original commit method. After the original commit method completes the local state commit, it generates a synchronization message based on the synchronization enable and synchronization mode items.

[0078] When the receiving tab processes changes to the Vuex state management library, it calls the corresponding method of the target instance again based on the method name or change name in the synchronization message, but does not write the synchronization enable item in the last parameter of this call to prevent the received state changes from being broadcast again.

[0079] S1.6.3. When the instance type is Vue Event Bus, override the $emit method of the target instance;

[0080] The wrapped `$emit` method identifies the configuration object from the end of the parameter sequence and passes the event name and other business parameters to the original `$emit` method for processing. When synchronization is enabled, the event name is used as the method name or event name in the synchronization message, and the event parameters are converted into transmittable metadata before being sent.

[0081] The receiving tab can trigger the listener function corresponding to the event name through the original event bus's listening mechanism. Since each tab can register different listener functions, the same event message can generate responses in different tabs that match the state of their respective pages.

[0082] S1.6.4. When the instance type is Mitt event emitter, override the emit method of the target instance;

[0083] The rewritten `emit` method retains the original calling relationship between event names and event parameters, and adds parsing of the configuration object in the last parameter. For event messages received across tabs, it queries the `all` property, which records the correspondence between event names and the set of listener functions, based on the event name, retrieves the corresponding array of listener functions, and executes them sequentially.

[0084] In other implementations, the original emit method of the target instance can be called to trigger the receiving event, but the event should be prevented from being sent again by using an internal call flag or by configuring without carrying a synchronization enable option.

[0085] S1.6.5. After rewriting the atomic operation method, maintain the original calling form of the atomic operation method, and trigger cross-tab synchronization after the atomic operation method is executed.

[0086] Preserving the original calling format includes maintaining the method name, the order of major parameters, the calling context, and the return value handling method. The configuration object is located in the last parameter, allowing the caller to add synchronization control information without changing the meaning of the preceding business parameters.

[0087] Synchronization is triggered after the atomic operation method completes, so that the synchronous message corresponds to the state change that has actually taken effect in the sending tab. For asynchronous atomic operation methods, "execution completed" can be set to the moment when the asynchronous operation successfully ends; for synchronous methods, message encapsulation and sending can be performed after the original method returns.

[0088] like Figure 3As shown, this embodiment, based on embodiment 1, refines the configuration object in the last parameter of the current call when the atomic operation method is called, obtaining a synchronization enable item for indicating whether cross-tab synchronization is enabled, and a synchronization mode item for indicating debouncing, throttling, immediate or visibility processing strategies, including the following steps.

[0089] S3.1. Determine whether the last parameter of this call is an object type. If the last parameter is an object type, use the last parameter as the configuration object.

[0090] Object type detection can exclude null values, basic data types, and array types that are unsuitable as configuration objects. When the last parameter meets the configuration object criteria, it further checks whether there is at least one of the following: synchronization enable item, synchronization mode item, or time interval item, to reduce the possibility of misidentifying ordinary business objects as configuration objects.

[0091] If the last parameter is not a configuration object, the call can use the target instance's base configuration. For atomic operation methods that need to receive object-type business parameters, the business object and configuration object can be distinguished through configuration field identifiers, dedicated configuration object types, or preset namespaces.

[0092] S3.2. Read the synchronization enable item of type boolean from the configuration object, the synchronization enable item being used to indicate whether cross-tab synchronization is enabled;

[0093] The corresponding value in the configuration object is used only when the synchronization enable item is a boolean value that meets the preset conditions. If the synchronization enable item is missing or its type does not meet the requirements, the synchronization enable item in the target instance's basic configuration or the preset default configuration is read.

[0094] When synchronization is enabled, the atomic operation will enter the synchronous message encapsulation process after local execution; when synchronization is disabled, the call will only be effective in the current tab.

[0095] S3.3. Read the synchronization mode item of the enumeration type from the configuration object. The value of the synchronization mode item is one of the debouncing strategy, throttling strategy, immediate strategy and visibility strategy.

[0096] The system can establish a mapping relationship between enumerated values ​​and sending policy processors. After reading the synchronization mode item, the corresponding processor is queried in the mapping relationship, and the synchronization message and time interval item are passed to the processor.

[0097] If the synchronization mode item is not among the preset enumerated values, it can fall back to the immediate policy or the policy indicated by the preset default configuration. The fallback method can be configured during the system initialization phase to balance configuration fault tolerance and the predictability of synchronization behavior.

[0098] S3.4. Read a numeric time interval item from the configuration object, the time interval item being used to indicate the time interval between the anti-shake strategy and the throttling strategy;

[0099] The time interval can be in milliseconds. After reading, a finite number check and non-negativity check can be performed, and values ​​exceeding the allowed range can be adjusted to boundary values ​​or replaced with the default time interval.

[0100] For debouncing strategies, the time interval term represents the waiting time from the last call to the sending of the synchronization message; for throttling strategies, the time interval term represents the minimum time interval between two consecutive allowed synchronization message sending. Immediate and visibility strategies may omit the time interval term.

[0101] S3.5. For any configuration items not provided in the configuration object, fill them in with the corresponding configuration items in the preset default configuration to obtain the synchronization enable item and the synchronization mode item that are effective in this call.

[0102] Configuration completion can be implemented using an item-by-item override approach. This involves using the default configuration as a base, first overriding valid configuration items from the initial configuration parameters, and then overriding valid configuration items from the current configuration object. The resulting configuration only applies to the current atomic operation method call and does not modify the global default configuration in reverse.

[0103] By using the layered configuration method described above, the caller can set a uniform synchronization strategy for most calls and override the synchronization mode item or time interval item only in specific calls, thereby reducing redundant configuration.

[0104] like Figure 4 As shown, this embodiment, based on embodiment 1, further refines the method name and parameters of the current call into a synchronization message when the synchronization enable item is enabled, and sends it through the synchronization channel according to the debouncing, throttling, immediate or visibility strategy corresponding to the synchronization mode item, including the following steps.

[0105] S4.1. Encapsulate the method name, the parameters, the type identifier indicating the category to which the target instance belongs, and the synchronization mode item into the synchronization message, and extract serializable metadata for the parameters;

[0106] Synchronous messages can use a key-value structure, where the method name field records the action name, submission name, or event name, the parameter field records the business parameters of this call, the type identifier field records the category to which the target instance belongs, and the synchronization mode field records the receiving and processing strategy.

[0107] Parameters are recursively checked during message encapsulation. Data that can be directly transmitted via broadcast channels is preserved; proxy objects can be converted into corresponding copies of the original data; functions and circular references can be filtered or converted into descriptive information. A version field can also be set in the message format so that the receiving tab can determine whether the message format is compatible with the current processor.

[0108] S4.2. When the synchronization mode item is an immediate policy, the synchronization message is placed in the sending queue and sent immediately through the synchronization channel;

[0109] The send queue is used to manage messages to be sent. Under the immediate policy, once a synchronization message enters the send queue, it is retrieved by the send processor and sent through the message sending interface of the broadcast channel instance.

[0110] Sending queues allow different strategies to share the same actual sending exit, facilitating serialization verification, channel status detection, and anomaly capture. When the channel is available and there are no pending messages blocking the way, enqueuing and sending can be completed within the same processing cycle.

[0111] S4.3. When the synchronization mode item is a visibility strategy, the synchronization message is sent immediately through the synchronization channel, and the receiving tab determines the processing time according to the page visibility.

[0112] The visibility strategy does not delay the sending of messages by the sending tab; instead, it delegates the decision to delay processing to each receiving tab independently. Therefore, the same synchronization message can be processed immediately by the currently visible tab and stored in its respective queue by the currently invisible tab.

[0113] Since the visibility status of each tab is independent of each other, setting the visibility judgment on the receiving end can avoid the sending tab maintaining the status information of other tabs and allow each receiving tab to determine the processing time based on its own running status.

[0114] S4.4. When the synchronization mode item is a debouncing strategy, the sending action is wrapped with a debouncing function, and the last synchronization message is sent after the delay time indicated by the time interval item in the configuration object expires.

[0115] The debouncing function maintains a debouncing timer and cached synchronization messages for the same debouncing dimension. The debouncing dimension can be determined by at least one of the target instance identifier, method name, or event name, ensuring that messages from different atomic operation methods do not overwrite each other.

[0116] By resetting the debouncing timer and replacing cached messages during consecutive calls, the sender only sends the final synchronization message after the delay time has elapsed since the consecutive calls stopped, thus compressing multiple intermediate states into a final state. This mechanism is suitable for scenarios where the receiving tab only needs to obtain the final result of the call sequence.

[0117] S4.5. When the synchronization mode item is a throttling strategy, the sending action is wrapped with a throttling function, and the synchronization message is sent only once within the interval indicated by the time interval item.

[0118] The throttling function records the most recent allowed transmission time for the corresponding throttling dimension. If the time difference between the current call and the most recent transmission is less than the specified time interval, the current transmission is suppressed or recorded as a message to be resent; after the specified time interval is reached, new synchronization messages are allowed to be sent.

[0119] In one implementation, the throttling strategy sends the first synchronization message within the time window. In another implementation, the last synchronization message can be sent at the end of the time window to balance timely response and final state synchronization. The specific method can be selected via configuration options, and this invention does not limit it.

[0120] Based on Example 5, this embodiment further refines the process of wrapping the sending action with a debouncing function when the synchronization mode item is a debouncing strategy, and sending the last synchronization message after the delay time indicated by the time interval item in the configuration object expires.

[0121] S4.4.1. When the atomic operation method is invoked, a debounce timer is started, and the timing duration of the debounce timer is taken from the time interval item;

[0122] Debouncing timers can be saved using a key combination of the target instance and method name. If no active timer exists for that key combination, a debouncing timer is created, and the current synchronization message is saved to the corresponding cache location.

[0123] The timeout duration determines how long to wait after continuous calls stop before sending the final message. For states with high update frequency and low latency sensitivity, a relatively long timeout duration can be set; for states requiring faster feedback, a relatively short timeout duration can be set.

[0124] S4.4.2. When the atomic operation method is called again during the debounce timer period, the debounce timer is reset and the cached synchronization message is replaced with the synchronization message of this call;

[0125] When the call occurs again, first cancel any debouncing timers that have not yet expired, then restart the timer using the same time interval. Simultaneously, the synchronization message generated by this call overwrites the previous synchronization message in the cache.

[0126] Because the cache always stores the synchronization message corresponding to the latest call, the message sent after a series of calls has ended can reflect the newer state of the sending tab. For cumulative operations that cannot be expressed by the final message alone, a debouncing strategy can be omitted, or the cumulative result can be converted into a directly applicable final state when encapsulating the message.

[0127] S4.4.3. When the anti-shake timer expires, the last cached synchronization message is sent through the synchronization channel and the cached synchronization message is cleared.

[0128] After the timer expires, the synchronization message is read from the cache, the broadcast channel instance is verified to be in an available state, and the message is sent. After the sending action is completed, the cached message and the corresponding debouncing timer record are deleted to prevent the invalid cache from continuously occupying memory.

[0129] If the broadcast channel instance is closed when the message is sent, the cached message can be discarded or the channel can be re-established according to preset retry rules. This embodiment preferably outputs a prompt and terminates the message transmission when the channel is unavailable to avoid infinite retries.

[0130] like Figure 5 As shown, this embodiment, based on embodiment 1, applies the state change carried by the synchronization message with the visibility strategy when the page is visible, and stores it in a waiting queue when the page is invisible. It also overwrites and merges similar non-cumulative state changes in the waiting queue to retain the latest final state. When the page visibility changes from invisible to visible, the merged synchronization messages in the waiting queue are processed sequentially. When the state change is applied, the synchronization enable item of the corresponding atomic operation method called is explicitly configured to be disabled to prevent secondary broadcasting from being refined. This includes the following steps.

[0131] S5.1. The message receiving listener of the synchronization channel in the receiving tab obtains the synchronization message and reads the synchronization mode item in the synchronization message;

[0132] The message receiving listener extracts message data from broadcast channel events and determines whether the message data has a preset synchronous message structure. After reading the synchronous mode item, the synchronous message is assigned to either the immediate processing path or the page visibility processing path.

[0133] For messages with a synchronization mode of immediate, debouncing, or throttling, the sending timing is determined at the sending end, and the receiving end can call the message processor after verification. For messages with a synchronization mode of visibility, the receiving end enters the page visibility query process.

[0134] S5.2. When the read synchronization mode item is a visibility policy, query the current page visibility status of the receiving tab;

[0135] Page visibility state can be read through browser-provided page visibility properties (such as the document.visibilityState property). When the receiving tab is in the foreground and interactive, the page visibility state is visible; when the tab is switched to the background or obscured by other pages to the point that it meets the browser's invisible criteria, the page visibility state is invisible.

[0136] If the current environment does not provide page visibility detection capabilities, the page state can be treated as visible so that synchronous messages can still be applied; alternatively, a pre-built compatible processor can be used to determine the timing of the alternative processing.

[0137] S5.3. When the page visibility state is visible, call the message processor corresponding to the type identifier of the synchronization message and apply the state change carried by the synchronization message;

[0138] Type identifiers categorize synchronization messages into messages corresponding to different instance categories. The receiving end maintains a registration relationship between type identifiers and message handlers, so that state management library changes and event bus messages are processed according to the invocation methods of the corresponding instances.

[0139] Because the message handler restores the method call relationship based on the type identifier, atomic operations in the sending tab can be mapped to corresponding operations in the receiving tab, thereby enabling the cross-tab transmission of state change or event messages.

[0140] S5.4. When the page visibility status is invisible, the synchronization messages are stored in the processing queue in the order of receipt, and the same type of non-cumulative state change messages with the same instance and the same method name in the processing queue are overwritten and merged to retain the latest synchronization message. The non-cumulative state change refers to the state change of the state result of the later call that can directly overwrite the state change of the previous call result.

[0141] The pending queue can adopt a first-in, first-out (FIFO) structure. Whenever a synchronization message using a visibility strategy is received, the message is appended to the end of the queue to preserve the order of messages. At the same time, if the message is a non-cumulative state change, the queue is checked to see if there is a cached synchronization message with the same target instance and the same method name. If it exists, the latest synchronization message is used to overwrite and the previously cached synchronization message is replaced with a duplicate.

[0142] To limit queue growth caused by prolonged periods of inactivity, a queue capacity limit can be set. For messages of the same type where the latest state can overwrite the previous state, they can be merged based on the target instance identifier and method name; for event-based or cumulative messages, they continue to be saved in the order they were received. Whether to perform message merging can be pre-configured based on the message type.

[0143] In this embodiment, the non-cumulative state change refers to a state change where the state result of a later call can directly overwrite the result of a previous call, such as updating the same state field or replacing the same configuration item or object entirely. Conversely, the cumulative state change refers to a state change where each change must be applied sequentially to obtain the correct result, such as incrementing a counter or appending entries to a list. For synchronous messages that belong to the cumulative state change category, the overwrite merging is not performed; instead, the messages are completely preserved and applied sequentially according to the order of receipt to ensure that each change takes effect.

[0144] S5.5. Listen for page visibility change events. When the page visibility change event indicates that the receiving tab has changed from invisible to visible, process all the merged synchronization messages in the pending queue in the order of receipt and clear the pending queue. When applying the state change, explicitly configure the synchronization enable item of the corresponding atomic operation method called to be disabled to prevent secondary broadcasting.

[0145] When initializing the receiving and processing module, the system registers a listener for page visibility change events (such as the visibilitychange event). When the event indicates that the page has become visible, it retrieves synchronous messages sequentially from the head of the merged and deduplicated pending queue, performs format validation, and calls the corresponding message handler. At the same time, when calling the atomic operation method on the receiving end, it explicitly disables the synchronization enable option in the parameters.

[0146] During queue processing, a snapshot of the current queue can be taken first, and then the original queue can be cleared, allowing newly received messages to enter a new queue or be processed directly. By applying state changes according to the order of receipt, the order of calls with sequential dependencies can be maintained.

[0147] This embodiment, based on embodiment 7, further refines the process of calling the message processor corresponding to the type identifier of the synchronization message and applying the state change carried by the synchronization message when the page visibility state is visible.

[0148] S5.3.1. Verify the message format and integrity of the synchronization message, and discard synchronization messages that fail the verification;

[0149] The validation criteria can include whether the synchronization message is an object type, whether the necessary fields exist, whether the type identifier is supported, whether the synchronization mode item belongs to the preset enumeration value, and whether the parameters meet the input requirements of the corresponding message processor.

[0150] For synchronous messages with incomplete format, mismatched field types, or version incompatibility, the atomic operation methods of the target instance will not be invoked, and the message will be discarded. The system can log validation failure information that does not contain specific business parameters for development debugging purposes.

[0151] S5.3.2. Query the message processor corresponding to the type identifier of the synchronization message in the message processor registry. The message processor registry is a mapping data structure with the type identifier as the key and the message processor as the value, which supports the dynamic addition and removal of message processors.

[0152] The message handler registry can use a mapping structure, with type identifiers as keys and message handling functions as values. During system initialization, the built-in state management library and event bus message handlers are registered, and extension adapters can also dynamically add message handlers for other target instances.

[0153] When removing a target instance or shutting down a related business module, the corresponding message handler can be removed simultaneously. If no message handler corresponding to the type identifier is found, processing of the current synchronous message will stop to avoid changing the receiving tab state using incorrect calling methods.

[0154] S5.3.3. When the type identifier indicates a change in the state management library, retrieve the method name and the parameter from the synchronization message, pass the parameter to the atomic operation method corresponding to the method name in the target instance, and call it;

[0155] The message processor first queries the target instance for the method corresponding to the method name and confirms that the method is callable. After confirmation, it uses the target instance as the calling context and passes the parameters from the synchronization message to the atomic operation method.

[0156] The receiving side call does not carry the enabled synchronization item, ensuring that the state change is applied only within the receiving tab and does not re-enter the sending process. This avoids the same state change being repeatedly broadcast between multiple tabs.

[0157] S5.3.4. When the type identifier indicates an event bus message, retrieve the event name and the parameter from the synchronization message, pass the parameter to the listening function array corresponding to the event name, and execute them sequentially;

[0158] The event bus message handler reads the array of listener functions registered on the receiving tab based on the event name. If the array of listener functions exists, they are called one by one in the registration order, with the parameters in the synchronization message serving as the input to the corresponding listener function.

[0159] Since different tabs can register different listener functions for the same event name, event messages do not require all tabs to form the same centralized state, but allow each tab to generate different responses based on its own page components and runtime context.

[0160] S5.3.5. After calling the atomic operation method or executing the listening function array, the receiving tab state is obtained, which is consistent with the sending tab state.

[0161] For changes to the state management library, the receiving tab executes the atomic operation method corresponding to the sending tab to ensure that the relevant state data remains consistent. For event bus messages, the consistent state described in this step can be represented by the receiving tab completing the expected state update corresponding to the event; the specific response content is determined by the listening function registered by the tab.

[0162] When a state change is not an idempotent operation, a synchronous message can pass parameters that can directly restore the final state, or the message processor can record the sequence of messages that have been processed to reduce the impact of repeated processing on the state result.

[0163] This embodiment provides browser compatibility, loop synchronization suppression, and application scenario configuration methods based on embodiment 1. The method also includes the following steps.

[0164] Step A. Before creating the broadcast channel instance, check whether the current browser environment supports the broadcast channel interface, and perform the creation if the broadcast channel interface is supported;

[0165] You can determine if the current browser environment supports the broadcast channel interface by checking if a callable broadcast channel constructor exists in the global runtime environment. If supported, create a broadcast channel instance and register a message receiving listener; if not supported, you can disable cross-tab synchronization and output a compatibility warning.

[0166] In other implementations, alternative communication channels can be established using stored events or shared worker threads, but the alternative communication channels still operate according to the same message format, configuration parsing method, and sending strategy.

[0167] Step B. When a state change call is triggered by the synchronization message, explicitly set the synchronization enable item to a disabled state in the parameter configuration object so that the state change call no longer sends a synchronization message through the synchronization channel;

[0168] When the receiving processing module calls the atomic operation method of the target instance, it explicitly sets the synchronization enable item to the disabled state in the parameter configuration object (for example, setting the configuration field crossTab to false). This explicit disable has a higher priority than the preset default configuration, so that the receiving side state change call will not enter the re-send process.

[0169] Internal processing states can also be set during the receive process, and these states can be identified by the overridden atomic operation methods. Regardless of the implementation method, the receiving-side call triggered by a broadcast message will not generate a secondary broadcast of the same message.

[0170] Step C. The broadcast channel instance does not send the synchronization message to the sending tab itself, thus omitting the source identifier in the synchronization message;

[0171] Broadcast channel instances deliver synchronization messages to other tabs that have joined the same channel, without sending the same message back to the current broadcast channel object that performed the sending action. Therefore, synchronization messages do not need to set a source identifier to exclude the sending tab itself, thus simplifying the message structure.

[0172] If an alternative communication method that sends messages back to the sender is adopted, a temporary instance identifier can be added and the receiver can filter its own messages; this alternative implementation does not affect the mechanism of the synchronization enable item to suppress circular sending.

[0173] Step D. For symmetric data synchronization scenarios requiring consistent states across multiple tabs, the target instance is taken as a state management library instance; for asymmetric state response scenarios where each tab responds differently based on its own state, the target instance is taken as an event bus instance.

[0174] In symmetric data synchronization scenarios, each tab stores the same type of shared state, such as application configuration state, operation progress state, or session display state. After retrieving the target instance as a state management library instance, the receiving tab calls the corresponding atomic operation methods to ensure that the relevant states in each tab become consistent.

[0175] In asymmetric state response scenarios, the sending tab only broadcasts events and parameters, while each receiving tab performs different operations based on its registered listener functions, page components, and visibility state. In this case, the target instance is taken as the event bus instance, thus separating event propagation from the specific responses of each tab.

[0176] To facilitate understanding of the technical means of this invention, the above technical solution is illustrated below with a specific application scenario. This example uses a health checkup registration service: In the front desk registration workstation of a health checkup institution, two tabs of the same web application are opened within the same browser. Tab A is the nurse's operation page, where the nurse adds or removes checkup items according to the user's needs; Tab B is the user confirmation page, used to display the selected checkup items and total cost to the user in real time. Each tab maintains its own state management library instance and connects to the same broadcast channel through unified adaptation processing. In this example, the synchronization enabled item, synchronization mode item, and time interval item are represented by the configuration fields crossTab, syncMode, and delay, respectively.

[0177] When a nurse adds or removes examination items for a user in tab A, tab A calls an atomic operation method from the state management library to submit the item change. In the configuration object of the last parameter, it configures the synchronization enable option to be enabled and the synchronization mode option to be set to immediate policy, for example, by passing in the configuration object {crossTab:true, syncMode:'immediate'}. After the atomic operation method completes locally, tab A encapsulates the method name and parameters into a synchronization message and immediately sends it via broadcast. Tab B receives this synchronization message through its message receiver listener and, because the page is visible, immediately calls the corresponding message handler to apply the item change, allowing the user to see the latest selected examination items and total amount in tab B in real time. The immediate policy is suitable for data that requires real-time synchronization, such as amounts, payment status, and key configurations.

[0178] When the registration form involves continuous input or high-frequency adjustments, tab A can configure the synchronization mode to a debouncing strategy and set a time interval, such as passing `{crossTab:true, syncMode:'debounce', delay:300}`. Then, after 300 milliseconds of continuous input stopping, only the synchronization message corresponding to the last state change will be sent. For calls that are continuously triggered and require limiting the sending frequency, such as drag-and-drop sorting, the synchronization mode can be configured to a throttling strategy, such as `{crossTab:true, syncMode:'throttle', delay:200}`, sending only one synchronization message every 200 milliseconds. This significantly reduces redundant synchronization messages generated by high-frequency calls, and the final state obtained by the receiving tab is consistent with that of the sending tab.

[0179] When tab B is switched to the background and becomes invisible, if the nurse continues to add or remove examination items in tab A, tab A still sends synchronization messages in real time according to the visibility policy, for example, by passing {crossTab:true, syncMode:'visibility'}. After receiving the synchronization message, tab B checks the page visibility status. Since it is currently invisible, it stores the synchronization messages in the pending queue in the order they were received, without immediately executing the state change. If the nurse adjusts the same examination item multiple times during this period, similar non-cumulative state changes with the same instance and method name are overwritten and merged in the pending queue, retaining only the latest final state. When the user re-views tab B and the page becomes visible again, tab B processes the merged synchronization messages in the pending queue sequentially. When applying the state change, it explicitly configures the synchronization enable item of the called atomic operation method to be disabled to prevent secondary broadcasting, thus allowing tab B to catch up with the latest selected examination items and total amount in one go with less computation.

[0180] Furthermore, for notification messages that require independent responses from each tab, the event bus instance can be used as the target instance. For example, after a nurse completes registration, a guidance event is sent from tab A via the event bus, such as `$emit('guideUser',{step:'pay'})`, carrying the configuration object `{crossTab:true, syncMode:'immediate'}`. Tab B then switches to the payment guidance interface based on its registered listener functions, while other tabs in the same application can respond differently according to their respective listener logic, achieving event synchronization in asymmetric state response scenarios.

[0181] The configuration field names, event names, time interval values, and business processes in the above examples are for illustrative purposes only and do not constitute a limitation on the scope of protection of this invention.

[0182] The correspondence between the above business code call flow and the various technical modules of this invention is as follows: Figure 7 As shown, the specific process includes: after the business code calls the atomic operation method, the adaptation and identification module completes the instance type identification and atomic operation method rewriting; the configuration parsing module parses the synchronization enable item, synchronization mode item, and time interval item from the configuration object of the last parameter; the sending strategy module completes the encapsulation and sending of the synchronization message according to the debouncing, throttling, immediate, or visibility strategy; the message is transmitted to the receiving tab through the broadcast channel established by the channel establishment module; and the receiving processing module completes message verification, page visibility judgment, pending queue overlay and merging, and message processor invocation, thereby applying the state change or triggering event response on the receiving tab.

[0183] like Figure 6As shown, this embodiment provides a multi-tab synchronization system that coordinates broadcast channels and page visibility, including an adaptation identification module, a channel establishment module, a configuration parsing module, a sending strategy module, and a receiving processing module.

[0184] An adaptation and identification module is used to detect the characteristic methods and attributes of the target instance to identify the instance type, and rewrite the atomic operation methods of the target instance according to the instance type while maintaining the original calling form and operation method. The atomic operation methods are the methods in the target instance used to complete state changes or event sending.

[0185] The adaptation identification module receives the target instance and optional initial configuration parameters. It identifies the Pinia state management library, Vuex state management library, Vue event bus, or Mitt event emitter based on the target instance's characteristic methods and attributes, and selects the corresponding adaptation logic. The adaptation identification module preserves the original processing functionality of the atomic operation methods, adding configuration parsing and synchronization trigger entry points to the wrapped methods.

[0186] The channel creation module is used to create broadcast channel instances with preset names as synchronization channels across tabs;

[0187] The channel establishment module detects whether the browser environment supports the broadcast channel interface. If supported, it creates a broadcast channel instance and sets up a message sending interface and a message receiving listener. The channel establishment module can also close the broadcast channel instance when the system exits, the target instance is logged out, or the page is uninstalled.

[0188] The configuration parsing module is used to parse the configuration object in the last parameter of the atomic operation method when the atomic operation method is called, and obtain the synchronization enable item for indicating whether cross-tab synchronization is enabled, and the synchronization mode item for indicating debouncing, throttling, immediate or visibility processing strategy.

[0189] The configuration parsing module determines whether the last parameter is an object type and reads the boolean synchronization enable item, the enumerated synchronization mode item, and the numeric time interval item from it. For any missing configuration items, the configuration parsing module completes the list according to the overriding relationship between call-level configuration, instance-level configuration, and preset default configuration.

[0190] The sending strategy module is used to encapsulate the method name and parameters of this call into a synchronization message when the synchronization enable item is enabled, and send it through the synchronization channel according to the debouncing, throttling, immediate or visibility strategy corresponding to the synchronization mode item.

[0191] The sending strategy module generates a synchronization message that includes a method name, parameters, type identifier, and synchronization mode item, and extracts serializable metadata for the parameters. The sending strategy module maintains records of the sending queue, debouncing timer, and throttling time, and selects the appropriate sending processor based on the synchronization mode item.

[0192] The receiving and processing module is used to, upon receiving a tab, apply the state change carried by the synchronization message using a visibility strategy when the page is visible, store it in a waiting queue when the page is invisible, and overwrite and merge similar non-cumulative state changes in the waiting queue to retain the latest final state; when the page visibility changes from invisible to visible, process the merged synchronization messages in the waiting queue sequentially; and when applying the state change, explicitly configure the synchronization enable item of the corresponding atomic operation method called to be disabled to prevent secondary broadcasting.

[0193] The receiving and processing module includes a message verification unit, a message processor registry, a page visibility detection unit, and a queue of messages to be processed. After successful message verification, the receiving and processing module queries the corresponding message processor based on the type identifier. For synchronous messages using a visibility strategy, they are temporarily stored when the page is not visible, and processed according to the receiving order when the page becomes visible. Each module can be implemented by a software program, executable instructions, or a combination of software and hardware functional units.

[0194] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for synchronizing multiple tabs with broadcast channels and page visibility, characterized in that, include: The characteristic methods and attributes of the target instance are detected to identify the instance type, and the atomic operation methods of the target instance are rewritten according to the instance type while maintaining the original calling form and operation method. The atomic operation methods are the methods in the target instance used to complete state changes or event sending. Create a broadcast channel instance with a preset name as a synchronization channel across tabs; When the atomic operation method is called, the configuration object in the last parameter of this call is parsed to obtain a synchronization enable item that indicates whether cross-tab synchronization is enabled, and a synchronization mode item that indicates debouncing, throttling, immediate or visibility processing strategy. When the synchronization enable option is enabled, the method name and parameters of this call are encapsulated into a synchronization message and sent through the synchronization channel according to the debouncing, throttling, immediate or visibility strategy corresponding to the synchronization mode option. When receiving a tab, for the synchronization message that adopts the visibility strategy, the state change carried by the synchronization message is applied when the page is visible, and stored in the pending queue when the page is not visible. The same type of non-cumulative state change in the pending queue is overwritten and merged to retain the latest final state. When the page visibility changes from invisible to visible, the merged synchronization messages in the pending queue are processed sequentially; when the state change is applied, the synchronization enable item of the corresponding atomic operation method called is explicitly configured to be disabled to prevent secondary broadcasting.

2. The method according to claim 1, characterized in that, The method and attributes of the detected target instance are used to identify the instance type, and the atomic operation methods of the target instance are rewritten according to the instance type while maintaining the original calling format and operation mode. The atomic operation methods are the methods in the target instance used to complete state changes or event sending, including: Receive the target instance and the initial configuration parameters passed in with the target instance, and when the initial configuration parameters are of object type, merge the initial configuration parameters into the preset default configuration; Detect whether the target instance has the $onAction method, $patch method, and $id attribute. If it has all of them, determine that the instance type is the Pinia state management library. Detect whether the target instance has a commit method, a _mutations attribute, and a _actions attribute. If all of them are present, determine that the instance type is a Vuex state management library. Detect whether the target instance has the $emit method and the $on method. If both are present, determine that the instance type is Vue Event Bus. Detect whether the target instance has an emit method, an on method, and an all property used to record the correspondence between event names and the set of listener functions. If all of these are present, determine that the instance type is a Mitt event emitter. Based on the determined instance type, the corresponding adaptation logic is invoked to rewrite the atomic operation method of the target instance. For target instances whose instance type is not determined, a warning message is output and the target instance is returned.

3. The method according to claim 2, characterized in that, The step of invoking the adaptation logic corresponding to the instance type determined by the judgment, and rewriting the atomic operation method of the target instance, includes: When the instance type is Pinia State Management Library, the execution of actions is monitored through the $onAction method of the target instance, and the crossAction method is used as the only entry point for cross-tab operations; When the instance type is a Vuex state management library, override the commit method of the target instance; When the instance type is Vue Event Bus, override the $emit method of the target instance; When the instance type is Mitt event emitter, override the emit method of the target instance; After rewriting the atomic operation method, the original calling format of the atomic operation method is maintained. The original calling format includes maintaining the method name, the order of the main parameters, the calling context, and the return value handling method. Cross-tab synchronization is triggered after the atomic operation method is executed.

4. The method according to claim 2, characterized in that, When the atomic operation method is invoked, the configuration object in the last parameter of this invocation is parsed to obtain a synchronization enable item indicating whether cross-tab synchronization is enabled, and a synchronization mode item indicating debouncing, throttling, immediate or visibility processing strategies, including: Determine whether the last parameter of this call is an object type. If the last parameter is an object type, use the last parameter as the configuration object. Read the synchronization enable item, a boolean value, from the configuration object. The synchronization enable item indicates whether cross-tab synchronization is enabled. Read the synchronization mode item of the enumeration type from the configuration object. The value of the synchronization mode item is one of the debouncing strategy, throttling strategy, immediate strategy and visibility strategy. Read a numeric time interval item from the configuration object, the time interval item being used to indicate the time interval between the debouncing strategy and the throttling strategy; For any configuration items not provided in the configuration object, the corresponding configuration items in the preset default configuration are used to complete the synchronization enable item and the synchronization mode item that are effective in this call.

5. The method according to claim 1, characterized in that, When the synchronization enable option is enabled, the method name and parameters of this call are encapsulated into a synchronization message and sent through the synchronization channel according to the debouncing, throttling, immediate, or visibility strategy corresponding to the synchronization mode option, including: The method name, the parameters, the type identifier indicating the category to which the target instance belongs, and the synchronization mode item are encapsulated into the synchronization message, and serializable metadata is extracted from the parameters; When the synchronization mode item is an immediate policy, the synchronization message is placed in the sending queue and sent immediately through the synchronization channel; When the synchronization mode item is a visibility policy, the synchronization message is sent immediately through the synchronization channel, and the receiving tab determines the processing time according to the page visibility. When the synchronization mode is set to a debouncing strategy, the sending action is wrapped in a debouncing function, and the last synchronization message is sent after the delay time indicated by the time interval item in the configuration object has expired. When the synchronization mode item is a throttling strategy, the sending action is wrapped with a throttling function, and the synchronization message is sent only once within the interval indicated by the time interval item.

6. The method according to claim 5, characterized in that, When the synchronization mode is set to a debouncing strategy, the sending action is wrapped in a debouncing function, and the last synchronization message is sent after the delay time specified in the time interval field of the configuration object has elapsed, including: When the atomic operation method is invoked, a debounce timer is started, and the duration of the debounce timer is taken from the time interval item; When the atomic operation method is called again during the debounce timer period, the debounce timer is reset and the cached synchronization message is replaced with the synchronization message of this call; When the anti-shake timer expires, the last cached synchronization message is sent through the synchronization channel and the cached synchronization message is cleared.

7. The method according to claim 1, characterized in that, When receiving a tab, for the synchronization message that adopts a visibility strategy, the state change carried by the synchronization message is applied when the page is visible, and stored in the waiting queue when the page is not visible. The same type of non-cumulative state change in the waiting queue is overwritten and merged to retain the latest final state. When the page visibility is detected to change from invisible to visible, the merged synchronization messages in the pending queue are processed sequentially. When applying the state change, explicitly configure the synchronization enable option of the corresponding atomic operation method being called to be disabled to prevent secondary broadcasting, including: The receiving tab receives the synchronization message through the message receiving listener of the synchronization channel and reads the synchronization mode item in the synchronization message; When the read synchronization mode item is a visibility policy, query the current page visibility status of the receiving tab; When the page visibility state is visible, the message processor corresponding to the type identifier of the synchronization message is invoked to apply the state change carried by the synchronization message. When the page visibility state is invisible, the synchronization messages are stored in the processing queue in the order of receipt, and the same type of non-cumulative state change messages with the same instance and the same method name in the processing queue are overwritten and merged to retain the latest synchronization message. The non-cumulative state change refers to the state change of the result of the later call that can directly overwrite the state change of the result of the previous call. Listen for page visibility change events. When the page visibility change event indicates that the receiving tab has changed from invisible to visible, process all the merged synchronization messages in the pending queue in the order of receipt and clear the pending queue. When applying the state change, explicitly configure the synchronization enable item of the corresponding atomic operation method called to be disabled to prevent secondary broadcasting.

8. The method according to claim 7, characterized in that, When the page visibility state is visible, the message processor corresponding to the type identifier of the synchronization message is invoked to apply the state change carried by the synchronization message, including: Verify the message format and integrity of the synchronization messages, and discard synchronization messages that fail the verification; The message processor is queried in the message processor registry to find the message processor corresponding to the type identifier of the synchronization message. The message processor registry is a mapping data structure with the type identifier as the key and the message processor as the value, which supports the dynamic addition and removal of message processors. When the type identifier indicates a change in the state management library, the method name and the parameter are retrieved from the synchronization message, and the parameter is passed to the atomic operation method corresponding to the method name in the target instance and invoked. When the type identifier indicates an event bus message, the event name and the parameter are retrieved from the synchronization message, the parameter is passed into the listening function array corresponding to the event name, and executed sequentially. After calling the atomic operation method or executing the listening function array, the received tab state is obtained, which is consistent with the sent tab state.

9. The method according to claim 1, characterized in that, The method further includes: Before creating the broadcast channel instance, it is checked whether the current browser environment supports the broadcast channel interface, and the creation is performed if the broadcast channel interface is supported. When a state change call is triggered by the synchronization message, the synchronization enable item is explicitly set to disabled in the parameter configuration object so that the state change call no longer sends a synchronization message through the synchronization channel; The broadcast channel instance does not send the synchronization message to the sending tab itself, thus omitting the source identifier in the synchronization message; For symmetric data synchronization scenarios requiring consistent states across multiple tabs, the target instance is taken as a state management library instance; for asymmetric state response scenarios where each tab responds differently based on its own state, the target instance is taken as an event bus instance.

10. A multi-tab synchronization system that coordinates broadcast channels and page visibility, characterized in that, include: An adaptation and identification module is used to detect the characteristic methods and attributes of the target instance to identify the instance type, and rewrite the atomic operation methods of the target instance according to the instance type while maintaining the original calling form and operation method. The atomic operation methods are the methods in the target instance used to complete state changes or event sending. The channel creation module is used to create broadcast channel instances with preset names as synchronization channels across tabs; The configuration parsing module is used to parse the configuration object in the last parameter of the atomic operation method when the atomic operation method is called, and obtain the synchronization enable item for indicating whether cross-tab synchronization is enabled, and the synchronization mode item for indicating debouncing, throttling, immediate or visibility processing strategy. The sending strategy module is used to encapsulate the method name and parameters of this call into a synchronization message when the synchronization enable item is enabled, and send it through the synchronization channel according to the debouncing, throttling, immediate or visibility strategy corresponding to the synchronization mode item. The receiving and processing module is used to, when receiving a tab, apply the state change carried by the synchronization message with the visibility strategy when the page is visible, store it in the waiting queue when the page is not visible, and overwrite and merge the same non-cumulative state changes in the waiting queue to retain the latest final state. When the page visibility changes from invisible to visible, the merged synchronization messages in the pending queue are processed sequentially; when the state change is applied, the synchronization enable item of the corresponding atomic operation method called is explicitly configured to be disabled to prevent secondary broadcasting.

Images