A lightweight event broadcasting method and system for front-end component state synchronization

Abstract

The application discloses a kind of lightweight event broadcast method and system for front-end component state synchronization, comprising the following steps: S1.component mounting and subscription initialization;S2.event publishing and type safety check;S3.intelligent broadcast filtering and target component screening;S4.event priority scheduling and callback execution;S5.component uninstallation and subscription automatic destruction.The application can realize efficient, stable and reliable state synchronization between front-end components, while significantly improving development experience and application performance.

Description

Technical Field

[0001] This invention relates to the field of front-end development technology, specifically to a lightweight event broadcasting method and system for front-end component state synchronization. Background Technology

[0002] In modern front-end application development, application architecture is typically built on a component-based approach, consisting of numerous nested or independent components. When components that are not in a parent-child relationship (such as sibling components or cross-level components) need to share or synchronize state, the traditional communication method of passing state down through props and bubbling it up through events leads to excessive coupling between components, complex code logic, and difficulty in maintenance. Therefore, the publish / subscribe pattern has become a widely adopted decoupling solution. It uses a centralized event bus as an intermediary, allowing components to subscribe to (on) specific events and emit events to pass data, thereby achieving indirect communication between components.

[0003] Existing lightweight event broadcasting implementations, such as the widely used Mitt library, while offering a minimalist API (on, emit, off) and a small size, reveal the following key technical shortcomings when facing the state management needs of complex enterprise-level front-end applications: (1) High risk of memory leak: The existing solution relies entirely on developers to manually manage the subscription lifecycle, that is, to actively call the unsubscribe (off) interface when the component is unloaded. In actual development, due to negligence, omissions in code refactoring, or improper handling of exception processes, the unsubscribe operation is easily missed. This causes the callback function of the unloaded component to still be held by the event bus instance and cannot be reclaimed by the garbage collection mechanism. As the application runtime increases, memory leaks will gradually occur, which may eventually lead to a decrease in application performance or even crash.

[0004] (2) Broadcasting is inefficient and wastes resources: Existing solutions typically use an "indiscriminate broadcasting" strategy when broadcasting events, that is, sending notifications to all components that have subscribed to the event name, without considering the actual state of the component (such as whether it is still mounted in the DOM) or the subset of data it really cares about. This results in a large number of invalid callback functions being executed (for unmounted components) and irrelevant component re-rendering (for components whose fields of interest have not changed), causing unnecessary CPU computation overhead and memory consumption. In scenarios with high-frequency state updates (such as real-time data streams and form input) or complex user interfaces (UI), the performance bottleneck is particularly prominent.

[0005] (3) Lack of type safety guarantees and poor synchronization reliability: Existing solutions are usually weakly constrained or completely unconstrained in terms of type systems. Event names rely on string matching, which is prone to spelling errors; the format of the transmitted state data is entirely agreed upon by the developer, lacking mandatory verification at compile time or runtime. This can easily lead to events not being received correctly, abnormal state data parsing (such as type conversion errors), or business logic errors caused by missing / redundant fields. These problems reduce the robustness of the state synchronization process and significantly increase debugging and maintenance costs.

[0006] (4) Inability to guarantee response to critical events: Existing solutions typically execute callback functions synchronously in the order they are registered (FIFO), lacking an abstraction of event priorities. In complex business scenarios, when critical events (such as user account cancellation, successful payment, and permission changes) are triggered simultaneously or nearly simultaneously with a large number of non-critical events (such as UI scrolling logs and animation frame updates), the callbacks for critical events may be blocked by the non-critical callbacks that follow, resulting in a delay in their response. This may lead to security issues (such as sensitive data not being cleaned up in a timely manner) or interruption of core business processes, affecting the overall reliability of the application and the user experience.

[0007] To address the aforementioned issues, some improvements have been attempted in existing technologies. For example, Chinese patent application CN116756457A discloses a method, apparatus, device, and computer-readable storage medium for sharing component state. Although this solution introduces centralized subscription management, analysis reveals significant shortcomings: First, it lacks verification of the "active state" of subscribed components, still broadcasting events to uninstalled but not unregistered components, thus failing to eliminate resource waste. Second, its state update triggering logic is rather coarse, failing to distinguish specific fields of state changes, requiring subscribed components to execute a complete update process upon receiving events, resulting in numerous irrelevant virtual DOM comparisons and re-rendering. Finally, this solution also lacks a built-in mechanism for validating state data, leaving data consistency risks unresolved.

[0008] Therefore, there is an urgent need in this field for an innovative lightweight event broadcasting mechanism that not only maintains the "lightweight" characteristic, but also systematically solves the core problems mentioned above, such as memory management, broadcast efficiency, type safety, and critical event protection, in order to meet the stringent requirements of modern front-end applications for high performance, high reliability, and high development efficiency. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a lightweight event broadcasting method and system for front-end component state synchronization, which can realize efficient, stable and reliable state synchronization between front-end components, while significantly improving the development experience and application performance.

[0010] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows.

[0011] A lightweight event broadcasting method for front-end component state synchronization includes the following steps: S1. Component Mounting and Subscription Initialization: In response to the mounting of a front-end component, obtain the subscription configuration of the component and automatically create a corresponding subscription record in the global subscription relationship registry; the subscription record includes at least the component identifier, event name, associated fields, callback function, priority, and active status, and the active status is marked as true; S2. Event Publishing and Type Security Validation: In response to any component's state change event publishing request, the event name and state data are validated according to preset rules. If the validation is successful, a standardized event is generated that includes the event name, publishing component identifier, state data, list of changed fields, priority, and publishing timestamp. S3. Intelligent broadcast filtering and target component selection: Based on the list of changed fields in the standardized events, query the global subscription relationship registry, perform dual filtering, and obtain the target component list; S4. Event Priority Scheduling and Callback Execution: Based on the priority of each subscription record in the target component list, the execution order of the callback functions of the target components is sorted, and the callback functions of each target component are triggered in the sorted order to transmit the state data in the standardized event; S5. Component Unloading and Automatic Subscription Destruction: In response to the uninstallation of a front-end component, automatically delete all subscription records corresponding to that component in the global subscription relationship registry.

[0012] Preferably, in step S1, the subscription configuration is provided by the component through a declarative API when it is mounted. The declarative API at least supports configuring event names, associated fields, callback functions, and priorities.

[0013] Preferably, in step S2, the preset rules include: Is the event name in the predefined event type enumeration list? Does the field format of the status data meet the requirements? The field format includes field type, required fields, and value range. Is the change field list a subset of the status data? In step S2, if the verification fails, an error message is returned to the corresponding component, and the event is terminated.

[0014] Preferably, in step S3, the dual filtering includes: First, iterate through the records in the global subscription registry that have subscribed to the corresponding event, and filter out the records with an active status of false; For the remaining records, determine whether there is any intersection between their associated field list and the changed field list, and only retain the records with intersection as the target component list.

[0015] Preferably, in step S4, the execution order of the callback functions of the target components is sorted, specifically: sorted from high to low priority, and sorted according to the subscription time for the same priority. In step S4, after the target component is triggered by the callback function, it updates the corresponding field value in the status data only according to the associated field defined in its subscription record.

[0016] Preferably, in step S5, when a component is uninstalled, all subscription records belonging to that component are searched for and deleted in the global subscription registry based on the component identifier.

[0017] A lightweight event broadcasting system for front-end component state synchronization, used to implement the method, the system comprising: The component lifecycle binding module is used to listen for the mounting and unmounting lifecycle events of front-end components, and send subscription initialization requests or subscription destruction requests to the event subscription management module accordingly. The event subscription management module has a bidirectional communication connection with the component lifecycle binding module, used for: Receive subscription initialization requests or subscription destruction requests sent by the component lifecycle binding module, update the global subscription relationship registry, and return a subscription status confirmation signal to the component lifecycle binding module; Receive event publishing requests published by components and forward them to the type safety verification module; The receiving type security verification module returns a verification pass signal and a standardized event, and then passes the standardized event and a global subscription relationship registry snapshot to the intelligent broadcast filtering module; Receive the target component list returned by the intelligent broadcast filtering module and pass the target component list to the event priority scheduling module; Receive the callback execution order returned by the event priority scheduling module, and trigger the callback functions of the target components in that order; The type security verification module is bidirectionally connected to the event subscription management module. It is used to receive event publishing requests forwarded by the event subscription management module, verify the legality of the event name and associated status data, and return a verification pass signal and standardized event to the event subscription management module after the verification passes. If the verification fails, it returns a verification failure signal and error information. The intelligent broadcast filtering module has a bidirectional communication connection with the event subscription management module. It is used to receive the standardized event and global subscription relationship registry snapshot transmitted by the event subscription management module, perform dual filtering based on the component's active status and associated fields, generate a list of target components, and return it to the event subscription management module. The event priority scheduling module has a bidirectional communication connection with the event subscription management module. It receives the target component list from the event subscription management module, sorts the execution order of callback functions according to the priority of each subscription record, and returns the callback execution order to the event subscription management module.

[0018] Preferably, the global subscription relationship registry is stored in a key-value pair structure, where the key is a component identifier and the value is an array consisting of one or more subscription records corresponding to that component.

[0019] Preferably, the type security verification module has a preset event type enumeration list and field format rules, which are used to match and verify the event name and to verify the type, required fields, and value range of each field in the status data.

[0020] Due to the adoption of the above technical solutions, the technical progress achieved by this invention is as follows.

[0021] This invention significantly improves operational stability and completely eliminates the risk of memory leaks: through an innovative "automatic binding mechanism between component lifecycle and subscription relationship," the creation and destruction of subscription records are strongly correlated with the component's mount / unmount lifecycle events. Developers do not need to write any code to manually unsubscribe; all subscriptions are automatically cleaned up when the component is unmounted. This fundamentally eliminates the risk of memory leaks caused by residual callback functions due to human error, ensuring the long-term, stable operation of the application.

[0022] This invention improves broadcast efficiency and optimizes resource utilization: by designing a "dual filtering mechanism based on active status and associated fields," it achieves intelligent and precise event broadcasting. First, it filters out uninstalled inactive components, avoiding unnecessary CPU computation; then, it filters out components whose fields of interest are irrelevant to the current change, avoiding redundant virtual DOM comparisons and UI re-rendering. This mechanism significantly reduces CPU and memory overhead under high-frequency updates and complex interfaces, avoids the resource waste caused by the "indiscriminate broadcasting" of existing technologies, and improves the overall performance and response speed of the application.

[0023] This invention enhances state synchronization reliability and reduces maintenance costs: By employing a "built-in type safety verification and event standardization mechanism," a mandatory security checkpoint is established at the event publishing entry point. Strict verification of event names, data formats, and field integrity ensures that all events circulating on the bus are legitimate and formatted uniformly, resolving synchronization anomalies caused by the lack of type constraints in existing technologies. This effectively prevents runtime anomalies due to incorrect types and inconsistent data formats, significantly improving the robustness of state synchronization between components and reducing debugging workload during the development phase.

[0024] This invention ensures the timeliness of critical business operations and improves application experience and security: by introducing an "event scheduling mechanism that supports priority configuration," the business side can assign priorities to events based on their importance. During event broadcasting, the execution order of callbacks is scheduled according to priority, ensuring that high-priority events (such as user logout or permission changes) are responded to before low-priority events. This is crucial for ensuring the timeliness of core business processes and the security of applications.

[0025] This invention provides more refined subscription relationship management, supporting efficient collaborative operation of functions: By designing a structured global subscription relationship registry with "component identifier - event name - associated field - priority - active status", which is uniformly maintained by the event subscription management module, it accurately records the key information of each subscription, providing real-time and accurate data input for mechanisms such as dual filtering and priority scheduling. It replaces the simple "event name - callback function" mapping storage method of existing technologies, realizes the visualization and traceability management of subscription information, reduces the difficulty of maintaining subscription relationships in multi-component and multi-event scenarios, and provides reliable data support for each core function.

[0026] This invention improves development efficiency and lowers the barrier to entry: Through automated (lifecycle management), standardized (type validation, event naming), and declarative (subscription configuration) design, it liberates developers from tedious manual management, defensive coding, and naming conventions. Developers only need to focus on "what to subscribe to" and "what to publish," without worrying about "when to unsubscribe," "whether the data is valid," or "whether there will be conflicts," thereby simplifying the code, reducing the complexity of state management logic, improving development efficiency, and lowering the barrier to entry for lightweight event broadcasting mechanisms. Attached Figure Description

[0027] Figure 1 This is a system diagram of the present invention; Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0028] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0029] A lightweight event broadcasting system for front-end component state synchronization, combined with Figure 1 As shown, it includes a component lifecycle binding module and an event subscription management module, a type safety verification module, an intelligent broadcast filtering module, and an event priority scheduling module, which are bidirectionally connected to the component lifecycle binding module.

[0030] (1) Component lifecycle binding module This is used to listen for the mount and unmount lifecycle events of all front-end components participating in state synchronization, and send a "subscription initialization request" or "subscription destruction request" to the event subscription management module accordingly. At the same time, it receives the "subscription status confirmation" signal returned by the event subscription management module, thereby automatically managing the creation and destruction of subscription relationships without manual intervention from developers.

[0031] (2) Event subscription management module This registry is used to maintain a global subscription relationship registry, recording the mapping relationship of "component identifier - event name - associated fields - callback function - priority". It responds to subscription creation / destruction requests, receives event publication signals, and forwards them to other modules, as detailed below: ① Receive subscription initialization requests or subscription destruction requests sent by the component lifecycle binding module, update the global subscription relationship registry, and return a "subscription status confirmation" signal to the component lifecycle binding module; ② Receive event publishing requests published by components and forward them to the type safety verification module; ③ Receive the verification pass signal and standardized event returned by the security verification module, and pass the standardized event and global subscription relationship registry snapshot to the intelligent broadcast filtering module; ④ Receive the "target component list" returned by the intelligent broadcast filtering module and pass the "target component list" to the event priority scheduling module; ⑤ Receive the "callback execution order" returned by the event priority scheduling module, and trigger the callback functions of the target components in order.

[0032] (3) Type security verification module It is used to receive event publishing requests forwarded by the event subscription management module, perform legality verification on the event name and associated status data, and return a verification pass signal and standardized event to the event subscription management module after successful verification. If the verification fails, it returns a verification failure signal and error message (such as "event type not defined" or "field format mismatch").

[0033] Specifically, the type security verification module has a pre-defined event type enumeration list and field format rules (such as field type, required fields, and value range) for matching and verifying event names and for verifying the type, required fields, and value range of each field in the status data according to the rules.

[0034] (4) Intelligent broadcast filtering module This is used to receive standardized events (including state change fields) and a snapshot of the global subscription relationship registry from the event subscription management module. It performs dual filtering based on the component's active state (indirectly obtained from the component lifecycle binding module) and associated fields (obtained from the global subscription registry) to filter out invalid subscribed components, generate a target component list (containing only currently active components with updated associated fields), and return it to the event subscription management module.

[0035] (5) Event Priority Scheduling Module Developers can configure priorities for events (such as high, medium, and low). This allows the system to receive a list of target components from the event subscription management module, sort the execution order of callback functions according to the priority of each subscription record, and return the "callback execution order" to the event subscription management module, ensuring that callbacks for high-priority events are executed before those for low-priority events.

[0036] The format of the global subscription relationship registry and standardized events in this system is as follows: (1) The global subscription registry uses a key-value pair structure for storage, where the key is the component identifier and the value is an array of one or more subscription records corresponding to that component. Specifically: { "Component Identifier_1": [ { Event Name: "user:update", "Related fields": ["name", "age"], "callback function": "callback_1", Priority: "high", "Active Status": true } ] "Component Identifier_2": [ { Event Name: "user:update", "Related field": ["email"], "callback function": "callback_2", Priority: "medium" "Active Status": false } ] } (2) Standardized event format (uniform format for publishing / transmitting) { Event Name: "user:update", "Release Component Identifier": "component_A", "Status data": { "name": "Zhang San", "age": 25, Email: zhangsan@xxx.com }, "List of changed fields": ["name", "age"], Priority: "high", Release timestamp: 1699999999999 } A lightweight event broadcasting method for front-end component state synchronization includes the following steps: S1. Component Mounting and Subscription Initialization: In response to the mounting of a front-end component, obtain the subscription configuration of the component and automatically create the corresponding subscription record in the global subscription relationship registry; the subscription record includes at least the component identifier, event name, associated fields, callback function, priority and active status, and marks the active status as true.

[0037] In this step, the subscription configuration is provided by the component through a declarative API when it is mounted. The declarative API at least supports configuring event names, associated fields, callback functions, and priorities.

[0038] S2. Event Publishing and Type Security Validation: In response to any component's state change event publishing request, the event name and state data are validated according to preset rules. If the validation is successful, a standardized event is generated that includes the event name, publishing component identifier, state data, list of changed fields, priority, and publishing timestamp.

[0039] In this step, the preset rules include: Is the event name in the predefined event type enumeration list? Does the field format of the status data meet the requirements? The field format includes the field type, required fields, and value range. Check whether the list of fields to be changed is a subset of the status data.

[0040] If the verification fails in this step, an error message is returned to the corresponding component, and the event is terminated.

[0041] S3. Intelligent Broadcast Filtering and Target Component Selection: Based on the list of changed fields in standardized events, query the global subscription relationship registry, perform dual filtering, and obtain the list of target components.

[0042] In this step, the dual filtering includes: First, iterate through the records in the global subscription registry that have subscribed to the corresponding event, and filter out the records with an active status of false; For the remaining records, determine whether there is any overlap between their associated field list and changed field list, and only retain the records with overlap as the target component list.

[0043] S4. Event Priority Scheduling and Callback Execution: Based on the priority of each subscription record in the target component list, the execution order of the callback functions of the target components is sorted, and the callback functions of each target component are triggered in the sorted order to pass the state data in the standardized event.

[0044] In this step, the execution order of the callback functions of the target components is sorted, specifically: sorted from high to low priority, and sorted by subscription time for the same priority.

[0045] In this step, after the target component's callback function is triggered, the corresponding field value in the state data is updated only based on the associated fields defined in its subscription record.

[0046] S5. Component Unloading and Automatic Subscription Destruction: In response to the uninstallation of a front-end component, automatically delete all subscription records corresponding to that component in the global subscription relationship registry.

[0047] In this step, when a component is uninstalled, all subscription records belonging to that component are searched for and deleted in the global subscription registry based on the component identifier. Example

[0048] A lightweight event broadcasting method for front-end component state synchronization is provided, implemented based on a lightweight event broadcasting system for front-end component state synchronization, such as... Figure 2 As shown, it includes the following steps: S1. Component Mounting and Subscription Initialization When a front-end component (such as front-end component A) completes mounting (triggers the mount lifecycle): Front-end component A declares the events it needs to subscribe to (such as "user:update"), associated fields (such as ["name", "age"]), callback functions, and event priorities (such as "high") through the API; The component lifecycle binding module listens for the mount event and sends a "subscription initialization request" to the event subscription management module, carrying the component identifier and event configuration information; After receiving the request, the event subscription management module adds the component's subscription record to the global subscription relationship registry, marks "active state" as true, and completes the subscription initialization.

[0049] S2. Event Publishing and Type Security Verification When the state of front-end component A changes (such as updating user name or age): front-end component A calls the event publishing interface (emit), passing in the event name ("user:update"), complete state data ({name: "Zhang San", age: 25, email: "zhangsan@xxx.com"}) and a list of changed fields (["name", "age"]); the event subscription management module receives the publishing request, extracts the event data, and passes it to the type security verification module; The type security verification module verifies the following according to preset rules: whether the event name is in the enumeration list (e.g., whether "user:update" is a predefined event); whether the field format of the status data meets the requirements (e.g., whether "age" is a numeric type and whether the value is within the range of 0-150); and whether the list of changed fields is a subset of the status data. If the validation fails, an error message is returned to front-end component A, and the event publishing is terminated; if the validation passes, standardized event data (conforming to a unified format) is returned to the event subscription management module.

[0050] S3. Intelligent Broadcast Filtering and Target Component Selection After receiving the validated event data, the event subscription management module transmits the event data and a snapshot of the global subscription relationship registry to the intelligent broadcast filtering module. The intelligent broadcast filtering module first filters components with an "active status" of false (such as the uninstalled front-end component B); then filters components that subscribe to the event but whose associated fields do not intersect with the "changed field list" (such as front-end component C that only subscribes to the "email" field; if the changed field is ["name", "age"], then front-end component C is filtered); finally, it generates a target component list (containing only currently active components with updated associated fields) and returns it to the event subscription management module.

[0051] S4. Event Priority Scheduling and Callback Execution After receiving the list of target components, the event subscription management module passes it to the event priority scheduling module. The event priority scheduling module extracts the "priority" information from the target component subscription records and sorts the execution order of the callback functions of each component in "high → medium → low" (for components with the same priority, they are sorted by subscription time). After sorting, the "callback execution order" is returned to the event subscription management module; the event subscription management module triggers the callback functions of the target components in sequence, passing in the standardized state data; Each target component receives state data through a callback function and only updates the fields associated with itself (e.g., if the front-end component D is associated with the "name" field, then only the name is updated, and the age and email are not processed), thus completing the state synchronization.

[0052] S5. Component uninstallation and automatic subscription destruction When front-end component A triggers its unmount lifecycle: the lifecycle binding module listens for the unmount event and sends a "subscription destruction request" to the event subscription management module, carrying the component identifier; After receiving a request, the event subscription management module deletes all subscription records for that component from the global subscription registry to ensure that the callback function is decoupled from the component and to avoid memory leaks.

[0053] The core innovations of this invention are as follows: (1) Automatic lifecycle binding mechanism By deeply monitoring the mount and unmount lifecycle events of front-end components, the creation and destruction of event subscription relationships are strongly bound to the component lifecycle. This mechanism fundamentally solves the omission problem caused by existing technologies relying on "manual unsubscription by developers," eliminating the need for developers to write additional destruction logic and achieving full automation of subscription management. This not only fundamentally eliminates the risk of memory leaks caused by callback function remnants but also significantly improves the long-term operational stability under lightweight architectures.

[0054] (2) Intelligent dual-filter broadcast mechanism A dual filtering strategy based on "component activity status" and "related fields" is introduced to achieve precise event delivery. First, the system filters out all uninstalled inactive components to avoid unnecessary computation and memory consumption. Second, among active components, only those whose "related fields" and the event's "change field list" intersect are selected as the final target. This mechanism significantly reduces invalid event broadcasts and the resulting redundant component re-rendering, solving the CPU and memory resource waste caused by traditional "indiscriminate broadcasting," and is the core of achieving efficient "lightweight" design.

[0055] (3) Built-in type security verification and event standardization mechanism By pre-setting a complete enumeration of event types and strict field format rules (including type, required fields, value range, etc.), mandatory dual validation of "event validity" and "data format" is implemented at the event publishing entry point. After successful validation, the system encapsulates the raw data into a standardized event with a unified structure. This mechanism effectively avoids synchronization anomalies such as misspelled event names, data type mismatches, missing key fields, or illegal values, and solves the persistent problems of low reliability and high debugging costs caused by the lack of type constraints in existing technologies.

[0056] (4) Event scheduling mechanism that supports priority configuration Developers can configure priorities (e.g., high, medium, low) for events or subscriptions. Before triggering a callback, the system dynamically sorts the execution order of callback functions of the target component based on the priority information recorded in the subscription registry (usually in the order of "high → medium → low," and for the same priority, sorted by subscription time). This design ensures in principle that critical business events receive priority responses, solving the response delay problem caused by critical events being blocked by ordinary events under the existing "no priority mechanism," thereby improving application security and response timeliness in complex business scenarios.

[0057] (5) Design of a structured global subscription registry An innovative, refined subscription relationship registry was designed with a structure of "component identifier - event name - associated fields - callback function - priority - active status". This registry uses a key-value pair format for storage and management, enabling not only global visualization and traceability of subscription information, but more importantly, providing real-time, accurate, and structured data support for the core mechanisms mentioned above, such as "dual filtering" and "priority scheduling". This fundamental design is the basis and guarantee for the efficient collaboration of various innovative functional modules and the realization of the overall technical solution.

Claims

1. A lightweight event broadcasting method for front-end component state synchronization, characterized in that: Includes the following steps: S1. Component Mounting and Subscription Initialization: In response to the mounting of a front-end component, obtain the subscription configuration of the component and automatically create a corresponding subscription record in the global subscription relationship registry; the subscription record includes at least the component identifier, event name, associated fields, callback function, priority, and active status, and the active status is marked as true; S2. Event Publishing and Type Security Validation: In response to any component's state change event publishing request, the event name and state data are validated according to preset rules. If the validation is successful, a standardized event is generated that includes the event name, publishing component identifier, state data, list of changed fields, priority, and publishing timestamp. S3. Intelligent broadcast filtering and target component selection: Based on the list of changed fields in the standardized events, query the global subscription relationship registry, perform dual filtering, and obtain the target component list; S4. Event Priority Scheduling and Callback Execution: Based on the priority of each subscription record in the target component list, the execution order of the callback functions of the target components is sorted, and the callback functions of each target component are triggered in the sorted order to transmit the state data in the standardized event; S5. Component Unloading and Automatic Subscription Destruction: In response to the uninstallation of a front-end component, automatically delete all subscription records corresponding to that component in the global subscription relationship registry.

2. The lightweight event broadcasting method for front-end component state synchronization according to claim 1, characterized in that: In step S1, the subscription configuration is provided by the component through a declarative API when it is mounted. The declarative API at least supports configuring event names, associated fields, callback functions, and priorities.

3. The lightweight event broadcasting method for front-end component state synchronization according to claim 1, characterized in that: In step S2, the preset rules include: Is the event name in the predefined event type enumeration list? Does the field format of the status data meet the requirements? The field format includes field type, required fields, and value range. Is the change field list a subset of the status data? In step S2, if the verification fails, an error message is returned to the corresponding component, and the event is terminated.

4. A lightweight event broadcasting method for front-end component state synchronization according to claim 1, characterized in that: In step S3, the dual filtering includes: First, iterate through the records in the global subscription registry that have subscribed to the corresponding event, and filter out the records with an active status of false; For the remaining records, determine whether there is any intersection between their associated field list and the changed field list, and only retain the records with intersection as the target component list.

5. A lightweight event broadcasting method for front-end component state synchronization according to claim 1, characterized in that: In step S4, the execution order of the callback functions of the target components is sorted, specifically: sorted from high to low priority, and sorted according to the subscription time for the same priority. In step S4, after the target component is triggered by the callback function, it updates the corresponding field value in the status data only according to the associated field defined in its subscription record.

6. A lightweight event broadcasting method for front-end component state synchronization according to claim 1, characterized in that: In step S5, when a component is uninstalled, all subscription records belonging to that component are searched for and deleted in the global subscription registry based on the component identifier.

7. A lightweight event broadcasting system for front-end component state synchronization, characterized in that, The system for implementing the method as described in any one of claims 1 to 6 comprises: The component lifecycle binding module is used to listen for the mounting and unmounting lifecycle events of front-end components, and send subscription initialization requests or subscription destruction requests to the event subscription management module accordingly. The event subscription management module has a bidirectional communication connection with the component lifecycle binding module, used for: Receive subscription initialization requests or subscription destruction requests sent by the component lifecycle binding module, update the global subscription relationship registry, and return a subscription status confirmation signal to the component lifecycle binding module; Receive event publishing requests published by components and forward them to the type safety verification module; The receiving type security verification module returns a verification pass signal and a standardized event, and then passes the standardized event and a global subscription relationship registry snapshot to the intelligent broadcast filtering module; Receive the target component list returned by the intelligent broadcast filtering module and pass the target component list to the event priority scheduling module; Receive the callback execution order returned by the event priority scheduling module, and trigger the callback functions of the target components in that order; The type security verification module is bidirectionally connected to the event subscription management module. It is used to receive event publishing requests forwarded by the event subscription management module, verify the legality of the event name and associated status data, and return a verification pass signal and standardized event to the event subscription management module after the verification passes. If the verification fails, it returns a verification failure signal and error information. The intelligent broadcast filtering module has a bidirectional communication connection with the event subscription management module. It is used to receive the standardized event and global subscription relationship registry snapshot transmitted by the event subscription management module, perform dual filtering based on the component's active status and associated fields, generate a list of target components, and return it to the event subscription management module. The event priority scheduling module has a bidirectional communication connection with the event subscription management module. It receives the target component list from the event subscription management module, sorts the execution order of callback functions according to the priority of each subscription record, and returns the callback execution order to the event subscription management module.

8. A lightweight event broadcasting system for front-end component state synchronization according to claim 7, characterized in that: The global subscription relationship registry is stored in a key-value pair structure, where the key is the component identifier and the value is an array consisting of one or more subscription records corresponding to that component.

9. A lightweight event broadcasting system for front-end component state synchronization according to claim 7, characterized in that: The type security verification module has a preset event type enumeration list and field format rules, which are used to match and verify event names and to verify the type, required fields, and value range of each field in the status data.

Images