A method, system, device, and medium for visual component linkage based on a state relay engine.

Abstract

This invention discloses a visualization component linkage method, system device, and medium based on a state relay engine. The method includes: constructing a global state repository in memory to store composite state objects containing state values, version stamps, and component subscription lists; the state relay engine performing debouncing processing on asynchronous state data reported by source components; performing multi-dimensional conflict suppression verification on the processed data; updating the state values ​​and version stamps after successful verification; based on the subscription list, calling a custom script through a multi-level transformation pipeline to logically process and asynchronously transform the state values, generating transformation data adapted to the target component; and accurately distributing the transformation data to the target component via a unidirectional data stream according to the trigger protocol type, driving updates to its interface parameters or attribute states. This invention achieves deep decoupling and reliable linkage between components, significantly improving the flexibility, performance, and stability of the configuration visualization platform in complex interactive scenarios.

Description

Technical Field

[0001] This invention relates to the field of front-end visualization and human-computer interaction technology, specifically to a visualization component linkage method, system, device, and medium based on a state relay engine. Background Technology

[0002] As enterprises deepen their digital transformation, configurable dashboards have become core tools for data monitoring and business decision-making. These platforms allow users to quickly build complex interactive interfaces by dragging and dropping components such as buttons, charts, and maps. However, existing technologies have the following significant shortcomings when implementing interactive linkage between multiple components: 1. High degree of interaction coupling and difficult maintenance: Traditional component linkage often adopts "hard-coded" or "point-to-point" configuration mode. When there are dozens of components on the page and the linkage logic is intertwined, a complex network coupling will be formed. Changes to any component may cause the entire linkage link to fail, and it is extremely difficult to troubleshoot errors.

[0003] 2. The linkage triggering mechanism is simple and inefficient: Existing configuration platforms typically only support simple numerical transmission, lacking the ability to perform logical cleaning, conditional filtering, and asynchronous transformation of data during transmission. Furthermore, in high-frequency triggering scenarios, the lack of debouncing and throttling mechanisms can easily lead to backend API overload and frontend rendering lag.

[0004] 3. Inconsistent State Synchronization and Circular Linkage Issues: In complex interaction logic, multiple components may share the same business state. Existing technologies lack a unified state management relay, which easily leads to data synchronization delays. More importantly, there is a lack of detection and suppression mechanisms for circular linkage (i.e., A triggers B, and B in turn triggers A), which can easily cause browser memory overflow or program deadlock.

[0005] Therefore, how to design a component linkage solution that can achieve deep decoupling while providing high performance and high reliability logic processing capabilities is a technical challenge that urgently needs to be solved in the current field of configuration visualization. Summary of the Invention

[0006] The technical problem to be solved by this invention is to overcome the shortcomings of the prior art and provide an asynchronous linkage method and system based on a state relay engine. By introducing a global state repository, a multi-level transition pipeline, and a conflict suppression mechanism, highly reliable and high-performance linkage in complex interaction scenarios is achieved.

[0007] To achieve the above objectives, the first aspect of the present invention adopts the following technical solution: A method for visualizing component linkage based on a state relay engine, the method comprising the following steps: S1. Construct a decoupled state relay engine: Allocate an independent cache area in the memory module as a global state repository, and store composite state objects in the global state repository; wherein, the composite state object includes state value, version stamp and component subscription list; The current value is used to store the latest data state, the version stamp is used to record the number of state changes, and the subscription list is used to record all target component IDs bound to the same variable and their corresponding trigger protocols, thus establishing a one-to-many mapping relationship from a single variable to multiple target components and their different trigger protocols; S2, Debouncing: The state relay engine receives and debouncing the asynchronous state data reported by the source component; S3. Conflict suppression verification: The state relay engine performs multi-dimensional conflict suppression verification on the data after debouncing, and updates the state value and version stamp in the composite state object after the verification is passed. S4. Asynchronous conversion pipeline processing: The state relay engine retrieves the target component and its trigger protocol according to the subscription list, and puts the updated state value into a multi-level conversion pipeline to convert it into conversion data that adapts to the input requirements of the target component; S5. Target Multidimensional Drive and Precise Rendering: Based on the type of the trigger protocol, the processed transformation data is distributed to different receiving ends of the target component through a unidirectional data flow mode, that is, only the specific affected component instances are notified, rather than a full page refresh, to perform data updates and / or attribute rendering.

[0008] Furthermore, the image stabilization process in step S2 includes: A configurable debouncing time window is preset for the status reporting of the source component; When multiple status reports are triggered consecutively within the anti-shake time window, only the status data generated by the last trigger is submitted to the status relay engine, and the previous intermediate status data is discarded to suppress invalid instantaneous concurrency.

[0009] Furthermore, the multidimensional conflict suppression verification described in step S3 includes: S31. State value comparison: The deep comparison algorithm is used to compare the state value of the linked variable in the reported data with the current state value of the composite state object. If the two are consistent, the linkage process is terminated to avoid invalid rendering. S32. Version verification: Determine the order of asynchronous requests based on version stamps, and only allow requests with higher version stamps to overwrite data from requests with lower version stamps, ensuring eventual data consistency in asynchronous scenarios and preventing old data from overwriting new data; S33. Loop Linkage Detection: Allocate an auto-incrementing call stack counter for each linkage link; if the linkage depth exceeds the preset threshold in a single interaction, it is determined to be a logical infinite loop and an interception action is executed to prevent system deadlock.

[0010] Furthermore, the multi-level conversion pipeline execution logic processing described in step S4 specifically includes: S41. Determine the target component based on the component subscription list, and extract the preset custom script from the trigger protocol corresponding to the target component; S42. In an isolated environment, the custom script is invoked to perform one or more of the following processes on the updated status value: formatting, logical judgment, and conditional filtering. S43. Initiate an asynchronous request to obtain external auxiliary data through the Promise mechanism and wait for the data to be returned. Combine the external auxiliary data with the results of the custom script execution, and convert the updated state value into transformed data that adapts to the input requirements of the target component, so as to provide a data adaptation basis for subsequent accurate distribution to the target component.

[0011] Furthermore, the trigger protocol types described in step S5 include at least: Interface-driven: Injects the transformed data into API request parameters or database query script variables to drive the component to retrieve the data source again; State-driven: Injects transformation data into one or more of the target component's CSS styles, visibility / hidden state configurations, and chart rendering parameters, enabling the component to transform in real time on the canvas.

[0012] Furthermore, the composite state object also includes a state variable name, which is a unique string identifier representing a specific business logic dimension, used to establish a subscription and addressing relationship between the state object and one or more target components in the global state repository.

[0013] The second aspect of the present invention provides a visual component linkage system based on a state relay engine, including a front-end linkage control unit and a component driving unit; The front-end linkage control unit includes a source component, a state relay engine, and a global state repository. The global state repository is communicatively connected to the state relay engine and stores multiple composite state objects. Each composite state object includes at least a state value, a version stamp, and a component subscription list. The source component captures user interaction operations or data change events, extracts the raw data generated by the interaction, generates asynchronous state data, and reports it. The state relay engine, as the core scheduling unit of the system, performs debouncing processing on the data reported by the source component and performs multi-dimensional conflict suppression verification on the debouncing data. Based on the verified state data, it updates the state value and version stamp in the composite state object. The component-driven unit includes a multi-level conversion pipeline and a task distribution module. The multi-level conversion pipeline is connected to a state relay engine. The state relay engine retrieves target components and their trigger protocols according to the subscription list, and transmits the updated state values ​​to the multi-level conversion pipeline for logical processing to generate conversion data. The task distribution module is used to push the conversion data processed by the multi-level conversion pipeline to the corresponding target component according to the trigger protocol type in the subscription list, so as to drive the update of the interface parameters and / or attribute state of the target component.

[0014] Furthermore, the state relay engine includes a debouncing processing module, a state value comparison module, a version verification module, and a cyclic linkage detection module connected in sequence.

[0015] A third aspect of the present invention provides an electronic device including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the method of any of the first aspects.

[0016] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of any of the first aspects.

[0017] The advantages and beneficial effects of this invention are as follows: 1. Decoupled architecture and precise distribution: The state relay engine completely decouples the logic of the source component and the target component. Adding or deleting components only requires modifying the subscription relationship to complete incremental updates, which greatly reduces maintenance costs. Combined with the unidirectional data flow distribution mode based on the trigger protocol, it realizes the precise push of transformed data and avoids invalid transmission and data filtering burden.

[0018] 2. Optimized performance and smooth operation: Through incremental updates, deep comparison and anti-bouncing mechanisms, the frequency of component rendering and backend interface calls is significantly reduced, improving the smoothness of large screen operation.

[0019] 3. High robustness and flexible logic: Through loop-linked detection and version control, it solves the problems of logical infinite loops and asynchronous data conflicts that are prone to occur in low-code configuration, ensuring system stability; it introduces a conversion script pipeline to achieve seamless adaptation of non-standardized data to various components, and enhances the configuration tool's ability to support complex business logic. Attached Figure Description

[0020] Figure 1 This is an architecture diagram of a front-end linkage control unit provided in an embodiment of the present invention; Figure 2 This is a logical structure diagram of a composite state object provided in an embodiment of the present invention; Figure 3This is a flowchart of the state relay engine provided in an embodiment of the present invention; Figure 4 This is an execution logic diagram of a multi-level conversion pipeline provided in an embodiment of the present invention.

[0021] In the diagram: 101, Source Component; 102, State Relay Engine; 103a, Target Component A; 103b, Target Component B; 201, Composite State Object; 202, State Value; 203, Version Stamp; 204, Subscription List; 204a, Subscription Item (Component A); 204b, Subscription Item (Component B); 301, Debouncing Module; 302, State Value Comparison Module; 303, Version Verification Module; 304, Loop Linkage Detection Module; 401, Multi-level Conversion Pipeline; 402, Interface Driver; 403, State Driver. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Example 1: like Figure 1 , Figure 2 As shown, this embodiment provides a visualization component linkage method based on the state relay engine 102. In this embodiment, when a user performs a click, selection, or value change operation on a component, the component does not directly search for the target component, but instead reports the generated raw data along with the predefined variable name to the state relay engine 102.

[0024] The visualization component linkage method includes the following steps: S1. Constructing a decoupled state relay engine 102: In the initial stage of system operation, an independent cache area is allocated in the memory module as a global state repository. This repository is configured to store one or more composite state objects 201, each object corresponding to a specific business logic variable; wherein, the composite state object 201 includes a state variable name, a state value 202, a version stamp 203, and a component subscription list 204. The subscription list 204 includes multiple subscription items, such as subscription item (component A) 204a and subscription item (component B) 204b, where 204a corresponds to component A and 204b corresponds to component B. This structure establishes a one-to-many mapping relationship from a single variable to multiple target components and their different triggering protocols. Each subscription item records a unique identifier of the target component and its triggering protocol. Through this list, the state relay engine 102 knows which components need to be notified and how to drive them when the value of the selected item identifier changes. Through this subscription list mechanism, the system achieves complete logical decoupling: the source component does not need to know the existence of the target component, but only needs to report variable changes to the state relay engine; while the target component automatically responds to changes by subscribing to the variable. This indirect communication mode completely cuts off the direct dependencies between components, so that adding, deleting, or modifying components only requires adjusting the subscription list, without reconstructing the linkage link, greatly reducing the system maintenance complexity.

[0025] S2. Debouncing: When the operator makes a selection operation, the source component 101 captures the interaction event, extracts the raw data generated by the interaction, generates asynchronous state data, and reports it; the state relay engine 102 receives and debouncing the asynchronous state data reported by the source component 101; the debouncing is based on the core principle of timer reset and invalid data discarding, and uses a configurable time window to shield high-frequency instantaneous state change requests, reducing the amount of invalid processing from the data input layer, and avoiding backend API overload due to high-frequency calls and frontend lag due to repeated rendering.

[0026] S3. Conflict Suppression Verification: The state relay engine 102 performs multi-dimensional conflict suppression verification on the data after debouncing, and updates the state value 202 and version stamp 203 in the composite state object 201 after the verification passes. The multi-dimensional conflict suppression verification is based on the principle of hierarchical filtering. Through three dimensions of verification—state value comparison, version verification, and loop linkage detection—it solves the three major problems of duplicate data, asynchronous timing disorder, and loop linkage, respectively, and ensures the validity, consistency, and stability of state data and system operation from the data verification layer.

[0027] S4. Asynchronous Conversion Pipeline Processing: The state relay engine 102 retrieves the target component and its trigger protocol according to the subscription list 204, traverses each subscription entry, and puts the updated state value 202 into the multi-level conversion pipeline 401 for processing and conversion into conversion data that adapts to the input requirements of the target component. The multi-level conversion pipeline is based on the processing principle of modularization and asynchronous integration, which breaks down data processing into multiple steps such as script extraction, logic processing, and external data fusion. It also supports custom scripts and asynchronous acquisition of external data, realizing flexible conversion of non-standard data into component-adaptive data, and improving the system's support capability for complex business logic from the data processing layer.

[0028] For each target component, the engine parses the trigger protocol defined in its subscription entry to identify the driver type and data mapping requirements. If the trigger protocol of that component is configured with logical transformation rules, the engine invokes the corresponding rules in a secure execution environment to process the original state value 202. This embodiment can configure rules for a component to convert the project identifier into another internal encoding format, or to determine whether certain display conditions are met based on the identifier. If no transformation rules are configured, the state value 202 is directly passed through; the transformed or passed-through data is encapsulated according to the format required by the target component's trigger protocol, ready for distribution.

[0029] S5. Target Multidimensional Driving and Precise Rendering: Based on the type of trigger protocol, a unidirectional data flow mode is used, i.e., only notifying the specific affected component instances instead of a full page refresh, to distribute the processed transformation data to different receiving ends of the target component, performing data updates and / or attribute rendering. The unidirectional data flow is based on the principle of unidirectional data transfer and precise addressing, allowing only state data to be pushed from the global state repository to the target component, and based on subscription relationships, only pushing to the affected components, avoiding data chaos caused by bidirectional state modifications by components. It also abandons the full refresh mode, improving the efficiency and accuracy of component linkage from the data distribution layer.

[0030] Example 2: like Figure 3 As shown, this embodiment provides a specific application of the configuration data visualization component linkage method based on the state relay engine 102 on the integrated command screen of a smart city operation center. This screen integrates multiple visualization modules, including a traffic flow heatmap (source component A), a weather warning information box (source component B), an emergency event list (source component C), an emergency resource distribution map (target component D), a key area monitoring panel (target component E), and a public notification preview component (target component F). Complex asynchronous linkage relationships exist between these components. For example, selecting a traffic congestion area may affect the emergency resource view, while changes in weather warning levels may require the linkage and updating of the status of multiple components.

[0031] S1. System Initialization and State Repository Construction: During application startup, the system initializes the state relay engine 102 and creates a global state repository in memory. The repository declares and initializes multiple composite state objects 201 related to the current business scenario, such as the selected traffic area, current weather warning level, and active event IDs. Based on the principle of independent memory caching, the global state repository stores composite state objects in a dedicated memory cache, isolated from other business caches, enabling high-speed reading and writing of state data. This meets the high real-time requirements of the visualization dashboard, while the unified state management mode avoids inconsistencies in state synchronization between multiple components.

[0032] Taking the current weather warning level object as an example, its initialization structure includes: the current value field is set to "none", the version stamp 203 field is set to 0, and the component subscription list 204 is pre-configured with the mapping relationship with the target components D, E, and F and their respective trigger protocols. The subscription list 204 establishes a one-to-many broadcast relationship from variables to multiple components.

[0033] S2. Anti-shake processing and status reporting: Source component A, i.e., the traffic flow heatmap, is configured to generate corresponding area codes when the operator clicks on different areas of the map. This component reports to the status relay engine 102 through a declarative interface, intending to update the selected traffic area variables.

[0034] During this process, the state relay engine 102 performs debouncing, pre-setting a configurable time window of 500ms for the reporting action. Its working logic is as follows: if the operator quickly and continuously clicks on multiple different areas within 500ms, generating a series of update requests for the selected traffic area variables, this module will only retain and process the area code data corresponding to the last click, while all intermediate area code data generated before this time window are automatically discarded. This debouncing mechanism essentially utilizes time window merging of high-frequency triggers, achieving a "last valid" strategy by discarding intermediate states, thereby merging multiple consecutive events into a single state update. This reduces the processing frequency of the state relay engine and the rendering pressure on downstream components from the source, making it a key optimization method for achieving high-performance system linkage. This effectively suppresses the instantaneous, high-frequency state change storm caused by rapid map browsing, avoiding unnecessary overload on backend services and frontend rendering.

[0035] S3. Multi-dimensional Conflict Suppression Verification: After receiving any state update request, the state relay engine 102 will perform strict multi-dimensional conflict suppression verification. This embodiment will use the processing of the current weather warning level update as an example. Suppose that the source component B, i.e., the weather warning information box, attempts to update its value from yellow to orange due to the warning upgrade.

[0036] S31, Status Value 202 Comparison: Status relay engine 102 first uses a deep comparison algorithm to compare the reported new value (orange) with the current value (yellow) currently stored in the global status repository for the current weather warning level object. If they are inconsistent, the verification passes, and the process proceeds to the next step. If they are the same, the process terminates immediately to prevent updates without substantial changes from triggering downstream linkages. The deep comparison algorithm uses a recursive field-by-field comparison principle, supporting accurate comparison of various types of business data such as numerical values, strings, and composite JSON. It ignores meaningless format differences such as spaces and field order, only judging the consistency of the actual business data content, fundamentally avoiding invalid linkages and rendering without substantial changes, and reducing unnecessary consumption of system resources.

[0037] S32, Version Verification: The state relay engine 102 checks the current version stamp 203 of the current weather warning level object, which is preset to 8. It ensures that only update requests with version numbers higher than the current value are processed. The implicit or explicit version information carried in this update is verified to be valid and in the correct order, such as the corresponding version 9. This mechanism ensures eventual data consistency even in the event of network latency or asynchronous callback contention. That is, a later, higher-version "orange" warning can correctly overwrite the previous version, without being incorrectly rolled back by a late "yellow" warning request. The version stamp mechanism assigns a globally ordered identifier to each state change, and the update sequence can be determined through simple numerical comparison. This effectively solves the problem of data overwriting chaos caused by the uncertain arrival order of requests in distributed or asynchronous scenarios, and is the core guarantee of system data consistency.

[0038] S33. Loop Detection: The engine maintains a call stack counter for the entire linkage triggered by the weather warning update. When the engine starts driving target components D, E, and F according to component subscription list 204, it tracks the depth of this linkage in real time. If, during the distribution process, a driven target component or its subsequent chain reaction attempts to modify the current weather warning level or other state variables that could trigger this linkage again, causing the call depth to exceed a preset safety threshold such as 5 layers, the engine will immediately determine that there is a potential risk of a logical infinite loop. At this time, the engine will execute an interception action, stop distributing to downstream components, and record detailed diagnostic logs, thereby fundamentally preventing system-level deadlocks or browser memory overflows caused by configuration errors. Loop detection proactively identifies and blocks potential infinite loops by monitoring call stack depth, avoiding infinite recursive calls caused by configuration errors, and greatly enhancing the robustness and self-protection capabilities of the system in complex and freely configurable scenarios.

[0039] After all checks pass, the engine atomically updates the current value of the current weather warning level object to "orange" and increments the version stamp 203 from 8 to 9.

[0040] S4. Multi-level asynchronous conversion pipeline processing: After the state update takes effect, the engine traverses the subscription list 204 for the current weather warning level. For the target component F in the list, namely the public notification preview component, its trigger protocol is configured to require complex data processing.

[0041] S41. Script Extraction and Preparation: The engine determines the target component F based on subscription list 204 and extracts the preset custom script from its corresponding trigger protocol. This script may contain logic such as generating different notification templates based on the warning level and querying the corresponding emergency plan number.

[0042] The principle of binding custom scripts with trigger protocols decouples data processing logic from components. Different components can be configured with different custom scripts to meet the personalized data processing needs of each component and improve the system's adaptability to complex and diverse business logic.

[0043] S42. Execution and Logic Processing in an Isolated Environment: The engine calls and executes the custom script within a secure, isolated environment. The script receives the updated status value 202 "Orange" as input and performs a series of logical processes: S421, Formatting: Change “orange” to the more formal descriptive text “Level III Warning”.

[0044] S422. Logical Judgment and Conditional Filtering: Determine whether the warning level meets the criteria for automatically generating pre-compiled notifications.

[0045] S423, External Data Fusion: The script logic includes operations that initiate asynchronous requests via the Promise mechanism. Based on the "orange" warning level, it asynchronously retrieves corresponding emergency plan details, contact lists of responsible departments, and other external auxiliary data from external knowledge bases or configuration services. The engine will wait for the return of such asynchronous requests.

[0046] The Promise mechanism is based on asynchronous, non-blocking, and state-management programming principles. When an external auxiliary data acquisition request is initiated, it will not block other processing flows in the multi-level transformation pipeline. The main system can continue to execute other operations. At the same time, through the three-state management of pending (waiting), fulfilled (success), and rejected (failure), it ensures that data fusion and processing are completed after the external data acquisition is successful, and that the data processing is handled according to the preset fallback rules after failure, thus ensuring the continuity and integrity of the data processing flow and avoiding the interruption of the entire linkage process due to the failure of the external data request.

[0047] S43. Data Synthesis and Adaptation: After the script execution is complete, the original warning status value, formatted text, logical judgment result, and acquired external auxiliary data are synthesized to finally output a structured data object that fully adapts to the input requirements of the target component F. This provides a well-adapted data foundation for subsequent accurate distribution. The multi-level transformation pipeline, by supporting custom scripts and asynchronous data acquisition, transforms the original status value into a data form rich in business semantics that can directly drive the target component. This state factory pattern allows linkage to go beyond data transmission, embedding complex business logic and integrating external data, thereby greatly expanding the boundaries of linkage capabilities and meeting the customized needs of complex business scenarios.

[0048] S5, Target Multidimensional Drive and Precise Rendering: Based on the types defined in the trigger protocols of each target component, the engine precisely distributes the data processed by the transformation pipeline to specific component instances through a unidirectional data flow mode.

[0049] like Figure 4 As shown, the trigger protocol types include: Interface-Driven 402: For the target component D, i.e., the emergency resource distribution map, its protocol type is Interface-Driven 402. The engine will transform the resource query-related parts of the data, such as the resource type filtering conditions derived from the warning level, and dynamically inject them into the predefined resource query API request parameters of this component. This automatically triggers the component to initiate a new data request to the backend to obtain emergency resource location data matching the current warning level, thereby refreshing the component content and re-rendering the resource distribution on the map. Based on the principles of data injection and proactive requests, the interface-driven approach injects the processed transformed data as query conditions into API request parameters or database query script variables, driving the component to proactively obtain the latest data source matching the current business status from the backend, realizing dynamic updates of component data and meeting the linkage needs of data query components.

[0050] State-driven 403: For target component E (key area monitoring panel) and target component F (public notification preview component), the protocol type is mainly state-driven 403. State-driven is based on the principle of direct property injection, directly injecting the transformation data into the target component's CSS styles, visibility configurations, chart rendering parameters, and other properties. This eliminates the need for backend requests, enabling real-time updates of the component view and meeting the low-latency linkage requirements of UI interactive components.

[0051] For component E, the engine will transform the UI-state-related parts of the data, such as the list of area IDs that need to be highlighted for monitoring, whether to display additional monitoring layers, etc., and directly inject them into the corresponding visibility configuration and chart rendering parameters of the component, driving its view to update immediately.

[0052] For component F, the engine assigns the synthesized complete notification preview data object to the component's internal content state property, enabling the component to switch and display the new notification preview on the canvas in real time, including adjusting CSS styles, such as changing the border color to orange to indicate urgency.

[0053] The unidirectional data stream distribution mechanism based on the trigger protocol ensures precise matching between the data push path and the consumption method of the target component. Whether it's driving a component to re-request data or directly updating the component's internal state, it only applies to specific component instances that have subscribed to the state variable. This avoids the invalid communication and rendering caused by traditional broadcast or full updates, achieving minimization and efficiency of linked updates.

[0054] Example 3: like Figure 1 As shown, this embodiment provides a visual component linkage system based on a state relay engine 102, including a state update unit and a component driving unit; The front-end linkage control unit includes a source component 101, a state relay engine 102, and a global state repository. The global state repository is communicatively connected to the state relay engine 102 and stores multiple composite state objects 201. Each composite state object 201 includes at least a state value 202, a version stamp 203, and a component subscription list 204. The source component 101 captures user interaction operations or data change events, generates asynchronous state data, and reports it. The relay engine 102 maintains the global state and performs logical distribution, driving target components such as target component A103a and target component V103b to respond. Based on the verified state data, the state value 202 and version stamp 203 in the composite state object 201 are updated. like Figure 4 As shown, the component driving unit includes a multi-level conversion pipeline 401 and a task distribution module. The multi-level conversion pipeline 401 is connected to a state relay engine 102. The state relay engine 102 retrieves the target component and its trigger protocol according to the subscription list 204, and transmits the updated state value 202 to the multi-level conversion pipeline 401 for logical processing to generate conversion data. The task distribution module is used to push the conversion data processed by the multi-level conversion pipeline 401 to the corresponding target component according to the trigger protocol type in the subscription list 204, so as to drive the interface parameters and / or attribute status update of the target component. The task distribution module is based on the dual addressing principle of subscription relationship and protocol type. It first determines the affected target component according to the subscription list, and then selects the corresponding distribution method according to the trigger protocol type to achieve accurate targeted push of conversion data, avoid invalid data transmission caused by broadcast distribution, and reduce the data filtering burden of the target component.

[0055] The state relay engine 102 includes a debouncing processing module 301, a state value comparison module 302, a version verification module 303, and a loop linkage detection module 304 connected in sequence. The internal modules of the state relay engine adopt a sequential pipeline processing principle, where the output of the previous module serves as the input of the next module. Data must pass through layers of processing, including debouncing, value comparison, version verification, and loop linkage detection. Only data that passes the verification of all modules will enter the state update stage, achieving multi-dimensional and full-process filtering and verification of state data. This ensures that the state data entering subsequent processes is valid and compliant. At the same time, each module has a single responsibility, facilitating independent maintenance and functional expansion.

[0056] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the visualization component linkage method based on the state relay engine 102 as described in the above embodiments. In a particular embodiment, the memory may be a non-volatile solid-state memory. In a particular embodiment, the memory includes a read-only memory (ROM).

[0057] The present invention also provides a computer-readable storage medium storing a computer program thereon, the computer program being executed by a processor to implement the visualization component linkage method based on the state relay engine 102 described in the above embodiments. The storage medium may be a non-volatile / non-transitory computer-readable storage medium.

Claims

1. A method for visualizing component linkage based on a state relay engine, characterized in that, Includes the following steps: S1. Construct a decoupled state relay engine: Allocate an independent cache area in the memory module as a global state repository, and store composite state objects in the global state repository; wherein, the composite state object includes state value, version stamp and component subscription list; S2, Debouncing: The state relay engine receives and debouncing the asynchronous state data reported by the source component; S3. Conflict suppression verification: The state relay engine performs multi-dimensional conflict suppression verification on the data after debouncing, and updates the state value and version stamp in the composite state object after the verification is passed. S4. Asynchronous conversion pipeline processing: The state relay engine retrieves the target component and its trigger protocol according to the subscription list, and puts the updated state value into a multi-level conversion pipeline to convert it into conversion data that adapts to the input requirements of the target component; S5. Target Multidimensional Driving and Precise Rendering: Based on the type of the trigger protocol, the processed transformation data is distributed to different receiving ends of the target component through a unidirectional data flow mode to perform data updates and / or attribute rendering.

2. The component linkage method according to claim 1, characterized in that, The image stabilization process in step S2 includes: A configurable debouncing time window is preset for the status reporting of the source component; When multiple status reports are triggered consecutively within the anti-shake time window, only the status data generated by the last trigger is submitted to the status relay engine, and the previous intermediate status data is discarded.

3. The component linkage method according to claim 1, characterized in that, The multidimensional conflict suppression verification in step S3 includes: S31. Status value comparison: Compare the status value of the linked variable in the reported data with the current status value of the composite status object. If the two are consistent, the linkage process is terminated. S32. Version verification: Determine the order of asynchronous requests based on version stamps, and only allow requests with higher version stamps to overwrite data from requests with lower version stamps; S33. Loop Linkage Detection: Allocate an auto-incrementing call stack counter for each linkage link; if the linkage depth exceeds the preset threshold in a single interaction, it is determined to be a logical infinite loop and an interception action is executed.

4. The component linkage method according to claim 1, characterized in that, The multi-level conversion pipeline execution logic processing described in step S4 specifically includes: S41. Determine the target component based on the component subscription list, and extract the preset custom script from the trigger protocol corresponding to the target component; S42. In an isolated environment, the custom script is invoked to perform one or more of the following processes on the updated status value: formatting, logical judgment, and conditional filtering. S43. Initiate an asynchronous request to obtain external auxiliary data through the Promise mechanism and wait for the data to be returned. Combine the external auxiliary data with the result of the custom script execution, and convert the updated state value into transformed data that adapts to the input requirements of the target component.

5. The component linkage method according to claim 1, characterized in that, The trigger protocol types mentioned in step S5 include at least: Interface-driven: Injects the transformed data into API request parameters or database query script variables; State-driven: Injects transformation data into one or more of the target component's CSS styles, visibility / hidden state configurations, and chart rendering parameters.

6. The component linkage method according to claim 1, characterized in that, The composite state object also includes a state variable name, which is a unique string identifier representing a specific business logic dimension, used to establish a subscription and addressing relationship between the state object and one or more target components in the global state repository.

7. A visual component linkage system based on a state relay engine, characterized in that, Includes front-end linkage control unit and component drive unit; The front-end linkage control unit includes a source component, a state relay engine, and a global state repository. The global state repository is communicatively connected to the state relay engine and stores multiple composite state objects. Each composite state object includes at least a state value, a version stamp, and a component subscription list. The source component captures user interaction operations or data change events, generates asynchronous state data, and reports it. The state relay engine debouncing the data reported by the source component and performs multi-dimensional conflict suppression verification on the debouncing data. Based on the verified state data, it updates the state value and version stamp in the composite state object. The component-driven unit includes a multi-level conversion pipeline and a task distribution module. The multi-level conversion pipeline is connected to a state relay engine. The state relay engine retrieves the target component and its trigger protocol according to the subscription list, and transmits the updated state value to the multi-level conversion pipeline for logical processing to generate conversion data. The task distribution module is used to push the conversion data processed by the multi-level conversion pipeline to the corresponding target component according to the trigger protocol type in the subscription list.

8. The component linkage method according to claim 7, characterized in that, The state relay engine includes a de-jitter processing module, a state value comparison module, a version verification module, and a cyclic linkage detection module connected in sequence.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed, implement the method as described in any one of claims 1-6.

Images