A rendering method and device of a front-end component and an electronic device

Abstract

The application discloses a front-end component rendering method and device and electronic equipment, and relates to the field of rendering. The reading behavior of a front-end component to a state identifier in a state data set is acquired, a reverse dependency relationship between the state identifier and an instance of the front-end component is established based on the reading behavior, in response to a change in a target state identifier in the state data set, a top-down rendering scheduling of a front-end framework by default is intercepted, a virtual node comparison process of a component node not dependent on the target state identifier is blocked, a target component instance dependent on the target state identifier is determined based on the reverse dependency relationship, and the target component instance is triggered to perform local rendering to skip an associated component node not subjected to state change. The application establishes a reverse dependency relationship between a state identifier and a component instance, intercepts a default rendering scheduling and blocks irrelevant node comparison when a state changes, accurately locates a target component to perform local rendering, and eliminates redundant calculation and rendering waterfall effect.

Description

Technical Field

[0001] This invention relates to the field of rendering technology, and more specifically, to a rendering method, apparatus, and electronic device for a front-end component. Background Technology

[0002] In modern web application development, front-end frameworks based on the Virtual DOM (Document Object Model) are widely used. These frameworks typically employ a top-down update mechanism. When the application state changes, the framework recursively generates a new virtual node tree, starting from the root node of the component tree or the point where the change is triggered, and compares the new virtual node tree with the old tree using a diff mechanism to determine the real DOM nodes that need to be updated.

[0003] However, in large-scale enterprise applications, such as data dashboards, low-code engines, or complex form systems, component trees often have extremely deep nesting levels and a massive number of nodes. This update mechanism in existing technologies means that even a minor change in the state of a low-level edge component can trigger a large number of parent and sibling components that do not depend on that state to participate in the regeneration and comparison calculation of virtual nodes. This high coupling between the state dependency structure and the view component tree structure results in severe redundant calculations and a rendering waterfall effect, leading to browser main thread blocking, dropped frames, and delayed interactive responses, failing to meet the demands for extreme rendering performance in complex scenarios. Summary of the Invention

[0004] In view of this, the present invention discloses a rendering method, apparatus and electronic device for front-end components, in order to solve the problem of low rendering performance caused by local state changes triggering full virtual node comparison due to coupling between state dependency and component tree structure in the prior art.

[0005] A method for rendering a front-end component, comprising:

[0006] Obtain the reading behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the reading behavior;

[0007] In response to a change in the target state identifier in the state data set, the default top-down rendering schedule of the front-end framework is intercepted, and the virtual node comparison process of component nodes that do not depend on the target state identifier is blocked.

[0008] Based on the reverse dependency, a target component instance that depends on the target state identifier is determined, and the target component instance is triggered to perform partial rendering to skip associated component nodes that have not undergone state changes.

[0009] Optionally, obtaining the front-end component's reading behavior of state identifiers in the state data set, and establishing a reverse dependency relationship between the state identifiers and instances of the front-end component based on the reading behavior, includes:

[0010] During the initialization rendering phase of the front-end component, a data proxy mechanism is used to intercept the front-end component's reading operation of the state identifier;

[0011] Record the read state identifier and associate the state identifier with the instance of the front-end component to generate a reverse dependency mapping graph.

[0012] Optionally, the interception of the front-end framework's default top-down rendering schedule, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier, includes:

[0013] An interceptor is mounted before the update scheduler in the front-end framework to capture change events of the target state identifier.

[0014] In response to the change event, the rendering state of component nodes that do not depend on the target state identifier is marked as skipped, or the component node is controlled to directly return to the cached historical virtual node, so as to block the regeneration and comparison of the virtual node of the component node.

[0015] Optionally, triggering the target component instance to perform partial rendering includes:

[0016] The local rendering tasks of the target component instance are pushed into the asynchronous task queue for batch processing.

[0017] In the next rendering frame, the local rendering task in the asynchronous task queue is directly triggered to execute the local rendering function of the target component instance.

[0018] Optionally, the rendering method further includes:

[0019] When the front-end component is mounted, a weak reference object is allocated to the instance of the front-end component, and the weak reference object is stored in the subscription set of the corresponding state identifier in the reverse dependency mapping graph;

[0020] When the front-end component triggers the uninstallation lifecycle hook, the reverse dependency mapping graph is traversed to identify the weak reference objects in the subscription set whose reference targets have been released by the garbage collection mechanism;

[0021] Remove invalid weak reference objects from the subscription set, and when the subscription set is empty, delete the key-value pair of the corresponding state identifier from the reverse dependency mapping graph, and unblock the data proxy listening of the state identifier.

[0022] Optionally, the rendering method further includes:

[0023] Obtain the original state data of the nested tree structure;

[0024] Traverse the tree nodes of the original state data, and for each leaf node or intermediate node that needs to be subscribed to independently, generate a unique hash key based on its path level and node attributes;

[0025] The nested objects in the original state data are expanded, and a flattened one-dimensional dictionary structure is constructed using the hash key as the key name and the corresponding node data as the key value to construct the state data set.

[0026] For each key-value pair in the one-dimensional dictionary structure, the application data proxy intercepts the data. When the node data is accessed or modified through the hash key, the corresponding dependency collection or change notification is triggered.

[0027] Optionally, the interceptor pre-mounted in the update scheduler of the front-end framework includes:

[0028] During the initialization phase of the front-end component, a custom dependency tracking hook is injected through a composite function. The dependency tracking hook is used to open the dependency collection context before the original rendering function is executed and to close the dependency collection context after execution.

[0029] The front-end component is wrapped with a higher-order wrapper component, and the update command issued by the update scheduler of the front-end framework is intercepted in the rendering logic of the higher-order wrapper component.

[0030] When the update instruction is received, the higher-order wrapper component checks whether the state identifier on which the front-end component depends has changed. If it has not changed, it directly returns the historical virtual node cached from the last rendering.

[0031] Optionally, directly triggering the local rendering task in the asynchronous task queue in the next rendering frame includes:

[0032] Bind the local rendering task in the asynchronous task queue to the browser's request animation frame callback;

[0033] Within each rendering frame triggered by the request animation frame callback, the local rendering task merged and batched in the asynchronous task queue is executed.

[0034] A rendering device for a front-end component, comprising:

[0035] The read behavior acquisition unit is used to acquire the read behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the read behavior.

[0036] The response unit is used to respond to a change in the target state identifier in the state data set, intercept the default top-down rendering schedule of the front-end framework, and block the virtual node comparison process of component nodes that do not depend on the target state identifier.

[0037] The rendering unit is used to determine the target component instance that depends on the target state identifier based on the reverse dependency relationship, and to trigger the target component instance to perform local rendering to skip the associated component nodes that have not undergone state change.

[0038] An electronic device, comprising: a memory and a processor;

[0039] The memory is used to store at least one instruction;

[0040] The processor is used to execute the at least one instruction to implement the rendering method of the front-end component.

[0041] As can be seen from the above technical solution, the present invention discloses a rendering method, apparatus, and electronic device for front-end components. By acquiring the reading behavior of front-end components on state identifiers in a state data set, a reverse dependency relationship is established between state identifiers and instances of front-end components. This makes the mapping between state data and view components independent of the hierarchical structure of the component tree, but directly points to the instance of the front-end component consuming the state using the state identifier as an index. On this basis, when the target state identifier in the state data set changes, the default top-down rendering schedule of the front-end framework is intercepted, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier. This prevents unrelated components from participating in the regeneration and difference comparison of virtual nodes during the update cycle. Furthermore, the target component instance that depends on the target state identifier is determined by querying the reverse dependency relationship, and the target component instance is triggered to perform local rendering. This ensures that the update operation only applies to the target component instance that actually depends on the state, skipping all associated component nodes that have not undergone state changes. Therefore, this invention reduces the computational overhead of rendering updates from being related to the depth of the component tree and the total number of nodes to being related only to the number of components that actually depend on the changed state. This cuts off the propagation path of redundant computation and the rendering waterfall effect caused by the coupling of the state dependency structure and the component tree structure. It effectively avoids the main thread blocking, page frame drops and interaction response delays caused by irrelevant components participating in virtual node comparison, and improves the rendering performance and interaction smoothness of complex front-end applications in high-frequency data update scenarios. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the published drawings without creative effort.

[0043] Figure 1 This is a flowchart of a front-end component rendering method disclosed in an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of the structure of a rendering device for a front-end component disclosed in an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] See Figure 1 The present invention discloses a flowchart of a front-end component rendering method, the method comprising:

[0048] Step S101: Obtain the reading behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the reading behavior.

[0049] Specifically, during the operation of the front-end application, the system does not rely on the parent-child hierarchy of components in the tree structure to pass state update notifications. Instead, it dynamically captures this data consumption behavior by monitoring the actual access operations of components to state data when executing rendering or initialization logic. For example, when a chart component reads the state identifier representing "real-time temperature" from the state data set during rendering, the system records the correspondence between the state identifier and the chart component instance. This establishment of a reverse dependency essentially transforms the implicit hierarchical coupling between state data and view components into an explicit point-to-point mapping graph. In this way, no matter how deeply a component is nested in the view tree, as long as it actually uses a certain state identifier, the system can establish a direct data-to-view index channel, providing a precise path for subsequent accurate updates and effectively avoiding the inefficient mechanism of blindly broadcasting updates based solely on the component tree structure.

[0050] Step S102: In response to a change in the target state identifier in the state data set, intercept the default top-down rendering schedule of the front-end framework and block the virtual node comparison process of component nodes that do not depend on the target state identifier.

[0051] Specifically, when the target state identifier in the state data set changes, existing front-end frameworks typically trigger a top-down recursive update process starting from the root node or the nearest common ancestor node. This forces many components that do not use the data to regenerate virtual nodes and perform difference comparisons. This embodiment introduces interception logic into the framework's update scheduling mechanism, intervening before the default full or subtree update task is executed. Once a change event of the target state identifier is captured, the system immediately identifies which component nodes have not subscribed to the target state identifier in the reverse dependency relationship and actively blocks the regeneration and comparison process of virtual nodes of these unrelated nodes. Therefore, the propagation path of redundant computation is cut off at the scheduling level, ensuring that computing resources are not wasted on view branches unrelated to the current data change, thereby effectively eliminating the rendering waterfall effect.

[0052] Step S103: Based on the reverse dependency relationship, determine the target component instance that depends on the target state identifier, and trigger the target component instance to perform local rendering to skip the associated component nodes that have not undergone state changes.

[0053] Specifically, after intercepting the default schedule and blocking irrelevant nodes, the system uses the constructed reverse dependency relationship as a query index to directly locate the set of all component instances that actually depend on the target state identifier. Subsequently, the system triggers a separate rendering update task for these target component instances, causing them to re-execute the rendering function to generate new virtual nodes and update the real DOM. During this process, even if the target component has parent, sibling, or other related components in the view tree, as long as these related components do not depend on the changed target state identifier, they will be completely skipped and will not participate in any form of re-rendering or comparison calculation.

[0054] For example, in a complex large-screen application containing thousands of nodes, if only one edge metric data is updated, the system only needs to refresh the specific component displaying that metric, while the remaining 99% of components remain silent. This targeted local rendering mechanism reduces the update time complexity from a linear level related to the total number of nodes in the component tree to a constant level related only to the actual number of dependent components, improving the interactive response speed and rendering frame rate of large front-end applications.

[0055] It should be understood that, although Figure 1The sequential execution logic of the above steps is illustrated. However, in actual engineering implementation, step S101 typically occurs during the component mounting or initial rendering phase, and is part of the dependency collection preparation process. Steps S102 and S103, on the other hand, are dynamic processing procedures that respond to data changes at runtime. Furthermore, the rendering method described in this embodiment is not limited to a specific front-end framework or programming language environment. The core concept of this invention can be applied to any technical scenario that employs a virtual DOM or similar component-based view mechanism and exhibits top-down update scheduling characteristics.

[0056] In summary, the front-end component rendering method provided by this invention establishes a reverse dependency relationship between the state identifier and the instance of the front-end component by acquiring the front-end component's reading behavior of the state identifier in the state data set. This ensures that the mapping between state data and view components does not depend on the hierarchical structure of the component tree, but directly points to the instance of the front-end component consuming the state using the state identifier as an index. Furthermore, when the target state identifier in the state data set changes, the method intercepts the front-end framework's default top-down rendering schedule, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier. This prevents unrelated components from participating in the regeneration and difference comparison of virtual nodes during the update cycle. Further, the method determines the target component instance that depends on the target state identifier by querying the reverse dependency relationship and triggers the target component instance to perform local rendering, ensuring that the update operation only applies to the target component instance that actually depends on the state, skipping all associated component nodes that have not undergone state changes. Therefore, this invention reduces the computational overhead of rendering updates from being related to the depth of the component tree and the total number of nodes to being related only to the number of components that actually depend on the changed state. This cuts off the propagation path of redundant computation and the rendering waterfall effect caused by the coupling of the state dependency structure and the component tree structure. It effectively avoids the main thread blocking, page frame drops and interaction response delays caused by irrelevant components participating in virtual node comparison, and improves the rendering performance and interaction smoothness of complex front-end applications in high-frequency data update scenarios.

[0057] In one embodiment, step S101 may specifically include:

[0058] (1) During the initialization rendering phase of the front-end component, the data proxy mechanism is used to intercept the front-end component's reading operation of the status identifier.

[0059] The initialization rendering phase of a front-end component refers to the complete execution cycle after the component instance is created and the rendering function is executed for the first time to generate virtual nodes. This phase is chosen as the window for dependency collection because the component's business logic will run completely at this time, and all state data actually consumed during the rendering process will be accessed.

[0060] Data proxy mechanisms are a technique that dynamically intercepts object property access at runtime. Their core lies in embedding a transparent middleware layer between the state data and the component without modifying the original state data structure. When component code attempts to read the value corresponding to a state identifier, the read request is first captured by the middleware layer, rather than directly returning the data value. For example, when a list component iterates through and reads the state identifier representing the "user list" during rendering, the data proxy mechanism automatically detects this property access behavior at the underlying level, without requiring developers to explicitly call subscription functions or declare dependency arrays in the business code. This "read-as-subscribe" runtime behavior completely decouples dependency collection logic from the business code, achieving automated collection of dependencies.

[0061] (2) Record the read state identifier and associate the state identifier with the instance of the front-end component to generate a reverse dependency mapping graph.

[0062] After receiving a read operation, the system will use the currently rendering front-end component instance as context information and bind it to the state identifier being read.

[0063] Specifically, the system maintains a global or module-level reverse dependency mapping graph. This graph's data structure represents a mapping relationship where state identifiers are keys and the sets of front-end component instances subscribing to that state are values. Whenever a new read operation is intercepted, the system searches for the set of component instances corresponding to that state identifier. If the current component instance does not yet exist in the set, it is added. For example, if the state identifier "Total Orders" is read successively by the "Top Navigation Bar Component" and the "Side Statistics Panel Component" during initial rendering, the key-value pair corresponding to "Total Orders" in the reverse dependency mapping graph will simultaneously contain instance references to both components. It should be understood that although this embodiment describes a data proxy mechanism based on object attribute interception, in other implementations, function call interception, computed property wrapping, or other equivalent runtime metaprogramming techniques can also be used to detect read operations, as long as the goal of automatically establishing the association between state and component is achieved without intruding on business logic code.

[0064] This embodiment uses the dynamic construction mechanism described above to automatically generate dependencies based on the actual data access path during component runtime. This eliminates the need for developers to manually declare dependencies or write subscription logic in their business code, reducing development and maintenance costs and avoiding dependency omissions or redundancy caused by manual declarations. At the same time, since the reverse dependency mapping graph always maintains strict consistency with the actual data consumption behavior of the component, it provides an accurate basis for subsequent interception of default rendering scheduling and blocking of irrelevant node comparisons. This avoids erroneous or missed updates caused by inaccurate dependency declarations, ensuring the correctness of view updates and the synchronous improvement of rendering performance.

[0065] In one embodiment, to further define the lifecycle management and memory safety mechanism of the reverse dependency mapping, the rendering method may further include:

[0066] When the front-end component is mounted, a weak reference object is allocated to the instance of the front-end component, and the weak reference object is stored in the subscription set of the corresponding state identifier in the reverse dependency mapping graph;

[0067] When the front-end component triggers the uninstallation lifecycle hook, the reverse dependency mapping graph is traversed to identify the weak reference objects in the subscription set whose reference targets have been released by the garbage collection mechanism;

[0068] Remove invalid weak reference objects from the subscription set, and when the subscription set is empty, delete the key-value pair of the corresponding state identifier from the reverse dependency mapping graph, and unblock the data proxy listening of the state identifier.

[0069] Specifically, during the establishment of reverse dependencies, directly storing strong references to component instances in the reverse dependency mapping graph can lead to memory retention by the garbage collector even after the component has been unloaded from the view tree. As application runtime increases and page switching becomes more frequent, this "only increasing, never decreasing" dependency accumulation will cause serious memory leaks. To address this deficiency, this embodiment introduces weak reference objects as the storage carrier for component instances in the graph. A weak reference object is a special reference type whose characteristic is that it does not prevent the garbage collection mechanism from reclaiming the target object it points to. When a component is mounted and a dependency is established, the system does not directly store the component instance itself, but instead creates a weak reference object pointing to that instance and adds it to the subscription set of the corresponding state identifier. This means that once the component is unloaded from the view tree and no other strong references point to it, the garbage collector can safely release the memory occupied by the component instance in the next garbage collection cycle. At this point, the graph only retains a weak reference shell pointing to an invalid target, thus breaking the memory retention caused by the dependency relationship.

[0070] However, relying solely on garbage collection to passively clean up weak references is insufficient, as a large number of invalid weak reference objects may accumulate in the graph between garbage collections, interfering with dependency lookup efficiency during state changes. Therefore, this embodiment also incorporates an active cleanup mechanism based on unloading lifecycle hooks, providing dual protection alongside the weak reference mechanism. When a front-end component triggers an unloading lifecycle hook, it indicates that the component is about to be or has already been removed from the view, and the system immediately initiates the cleanup process. In this process, the system traverses the reverse dependency map graph, checking whether weak reference objects in each subscription set are still valid. For weak reference objects whose targets have been released by the garbage collection mechanism, or objects confirmed to be invalid through active detection, the system removes them from the subscription set. This active removal strategy ensures that the reverse dependency map graph maintains a compact and accurate state at runtime, avoiding unnecessary traversal of invalid nodes when state changes trigger updates, and guaranteeing the performance stability of targeted rendering.

[0071] Furthermore, when the subscription set corresponding to a certain state identifier becomes empty after removing invalid objects, it means that no active component instances currently depend on that state identifier. At this point, the system not only removes the key-value pair corresponding to that state identifier from the reverse dependency mapping graph, but also simultaneously unloads the data proxy listener attached to that state identifier. This step is crucial because the data proxy mechanism itself consumes certain memory resources and computational overhead. If the state data is no longer consumed by any view, continuing to maintain its proxy interception logic is not only a waste of resources, but may also trigger invalid change notifications when the data is modified later. By unloading the proxy listener, the system achieves complete resource release from data structures to listening logic, ensuring a smooth memory usage curve for the entire rendering system during long-term operation and effectively avoiding performance degradation caused by dependency residue.

[0072] It should be understood that although this embodiment describes a cleanup method based on a combination of weak reference objects and unloading hooks, other equivalent memory management methods can be used in different runtime environments or programming languages. For example, in some environments that do not support native weak references, a soft reference caching strategy with expiration timestamps can be used, or orphaned nodes can be identified and removed through periodic full scans and mark-and-sweep algorithms. Regardless of the specific implementation used, as long as it can achieve the purpose of timely unbinding the component from its state identifier after component destruction and preventing the dependency graph from expanding indefinitely, it falls within the protection scope of this application.

[0073] This embodiment completes the technical closed loop of the reverse-dependent rendering scheme through the aforementioned lifecycle management mechanism, enabling it to not only possess accurate rendering capabilities but also the long-term operational stability and memory security required by enterprise-level applications.

[0074] In one embodiment, to further define the specific implementation method and non-intrusive mounting mechanism of rendering scheduling interception and blocking, the process of mounting the interceptor before the front-end framework updates the scheduler may specifically include:

[0075] During the initialization phase of the front-end component, a custom dependency tracking hook is injected through a composite function. The dependency tracking hook is used to open the dependency collection context before the original rendering function is executed and to close the dependency collection context after execution.

[0076] The front-end component is wrapped with a higher-order wrapper component, and the update command issued by the update scheduler of the front-end framework is intercepted in the rendering logic of the higher-order wrapper component.

[0077] When the update instruction is received, the higher-order wrapper component checks whether the state identifier on which the front-end component depends has changed. If it has not changed, it directly returns the historical virtual node cached from the last rendering.

[0078] Specifically, to achieve control over rendering scheduling without modifying the front-end framework source code or intruding on business component code, this embodiment employs a non-intrusive architecture where composite functions and higher-order wrapper components work together. A composite function is a reusable logical encapsulation unit designed to execute automatically during component initialization. When a business component introduces this composite function, the function injects a custom dependency tracking hook into the current component instance. The core function of this hook is to automatically open a global or thread-local dependency collection context before each execution of the original rendering function, ensuring that all state reads occurring within the rendering function are correctly captured and associated with the current component by the data proxy mechanism. After the rendering function completes, the hook immediately closes the context to prevent dependency collection scope overflow from polluting other components. This mechanism completely decouples dependency tracking logic from business code; developers do not need to manually write subscription or unsubscribe code, but only need to introduce a single function to obtain accurate rendering capabilities.

[0079] Building upon this, a higher-order wrapper component acts as a physical interception layer, encasing the original front-end components. While occupying the original component's position in the view tree, the higher-order wrapper component's rendering logic doesn't directly generate the UI structure; instead, it acts as a smart gateway. When the front-end framework's update scheduler attempts to dispatch update instructions downwards, the instructions first reach the higher-order wrapper component. At this point, the higher-order wrapper component queries the reverse dependency mapping graph to check if its wrapped internal components truly depend on the target state identifier that triggered the update. If the check indicates that the internal component does not depend on the changed state, the higher-order wrapper component directly returns a historical virtual node reference cached during the last rendering, without passing the update instruction to the internal component. Since the returned virtual node reference is identical to the existing reference in memory, the framework's underlying difference comparison algorithm immediately determines that the node has not changed, thus skipping the recursive comparison process of the entire subtree with minimal computational cost. This design makes the interception logic completely transparent to the business components, preserving the original component's code purity while providing it with on-demand update performance.

[0080] Furthermore, regarding the specific blocking strategy after interception, this embodiment provides two implementation paths adaptable to different framework characteristics. Specifically, step S102 may include:

[0081] The first blocking path includes: attaching an interceptor before the update scheduler of the front-end framework, and capturing the change event of the target state identifier through the interceptor.

[0082] Specifically, the first blocking path involves marking the rendering state of component nodes that do not depend on the target state identifier as skipped. This approach is suitable for front-end frameworks that internally expose scheduling optimization interfaces or support Bailout mechanisms. After capturing a change event, the interceptor quickly filters out a set of irrelevant components based on reverse dependencies and sets the state of these components in the scheduling queue to "skipped" or "no need to update" through the framework's internal API (Application Programming Interface) or agreed-upon attribute markers. When the scheduler traverses the component tree to execute update tasks, once it detects this marker, it directly ignores the node and all its child nodes, no longer calls its rendering function, and does not perform any virtual node generation operations. The advantage of this path is that it eliminates computational tasks from the source of scheduling, avoids the execution overhead of rendering functions, and is the most performance-optimized blocking method.

[0083] The second blocking path includes: in response to the change event, marking the rendering state of component nodes that do not depend on the target state identifier as skipped, or controlling the component node to directly return to the cached historical virtual node, so as to block the regeneration and comparison of the virtual node of the component node.

[0084] The second blocking path involves controlling component nodes to directly return cached historical virtual nodes. This approach is more versatile, especially suitable for frameworks that do not expose scheduling layer intervention interfaces but adhere to virtual DOM reference equality rules. In this path, the interceptor does not attempt to modify the scheduler's internal state but intercepts at the component's rendering function entry point, forcing it to return the old virtual node object reference saved in the previous rendering cycle. For the framework's difference comparison engine, identical old and new virtual node references mean that the node and its subtree have not changed, thus automatically short-circuiting subsequent deep comparison logic. Although this method still triggers rendering function calls (or is intercepted by higher-order components), it significantly reduces update time by avoiding expensive Diff calculations and DOM operations. In practical engineering applications, the system can automatically select the optimal path based on the current front-end framework type, or allow developers to specify blocking strategies through configuration options, thereby maximizing adaptability to diverse technology stacks while ensuring core functionality consistency.

[0085] This embodiment constructs a core defense depth that differs from traditional reactive libraries through the aforementioned non-intrusive mounting and dual blocking mechanisms. Traditional solutions often can only reduce re-rendering within components through fine-grained signals or manual optimization, but cannot prevent top-down scheduling propagation at the framework level. This application successfully cuts off the update propagation link before it reaches irrelevant nodes by placing an interceptor before the scheduler and combining it with caching decisions of higher-order components.

[0086] In one embodiment, the process of triggering a target component instance to perform partial rendering specifically includes:

[0087] The local rendering tasks of the target component instance are pushed into the asynchronous task queue for batch processing.

[0088] In the next rendering frame, the local rendering task in the asynchronous task queue is directly triggered to execute the local rendering function of the target component instance.

[0089] Specifically, in complex interactive scenarios, changes in state data are often frequent and intensive. For example, when a user drags a slider or receives a real-time data stream, dozens or even hundreds of state updates may be triggered consecutively within a very short time window. If the system immediately executes the component's rendering function for each state change, it will not only lead to a large number of invalid renderings of intermediate states, but also cause UI lag due to frequent preemption of the main thread.

[0090] To address this issue, this embodiment introduces an asynchronous task queue as a buffer pool for rendering tasks. Once a target component instance requiring updating is identified through reverse dependencies, the system does not immediately execute its rendering logic. Instead, it pushes the component instance's identifier or the corresponding rendering task handle into a globally shared asynchronous task queue. During task enqueuing, the system executes batch merging logic, checking if a task for the same component instance already exists in the queue. If it does, a preset strategy is used to either retain the latest task parameters or merge the update load, ensuring that each component instance is rendered at most once within the same batch. This deduplication and merging mechanism eliminates redundant computations caused by repeatedly triggering updates to the same component within a short period, significantly reducing the rendering load.

[0091] In one embodiment, the process of directly triggering a local rendering task in the asynchronous task queue in the next rendering frame may specifically include:

[0092] Bind the local rendering task in the asynchronous task queue to the browser's request animation frame callback;

[0093] Within each rendering frame triggered by the request animation frame callback, the local rendering task merged and batched in the asynchronous task queue is executed.

[0094] Specifically, requesting animation frames is a native API provided by the browser, and its callback function is designed to execute in strict synchronization with the display's refresh cycle. By registering the execution entry point of the aforementioned asynchronous task queue to the callback of requesting animation frames, the system can automatically align all pending local rendering tasks to be executed in a concentrated manner during the idle period before the browser's next repaint. This means that regardless of when the state change occurs within the current frame, the relevant rendering tasks will be collected and batch-processed at a unified time point in the next frame.

[0095] This frame synchronization scheduling mechanism brings dual technical benefits: on the one hand, it ensures that the DOM update operation and the screen drawing operation are in sync, avoiding screen tearing or flickering caused by the misalignment of rendering completion time and refresh cycle; on the other hand, it normalizes the originally discrete and random rendering tasks into periodic batch jobs, enabling the browser to plan subsequent pipeline stages such as style calculation, layout reflow and compositing layer drawing more efficiently, thereby maximizing the use of hardware acceleration capabilities.

[0096] It should be understood that although this embodiment preferably uses request animation frames to achieve frame synchronization, in some operating environments that do not support this feature, timer simulation or other equivalent frame rate adaptation mechanisms can also be used as alternatives. As long as the purpose of aligning the rendering task with the display refresh cycle can be achieved, they all fall within the protection scope of this application.

[0097] This embodiment constructs a smooth transition channel from state changes to view updates through the coordinated operation of asynchronous batch processing and frame synchronization scheduling. Compared to the real-time responsive rendering mode in traditional solutions, this application elevates the update granularity from "single event" to the "rendering frame" level. This preserves the user's real-time perception of interactive responses (because the latency is controlled within approximately 16ms per frame) while effectively avoiding performance jitter caused by high-frequency updates. Especially in extreme scenarios such as dynamic data dashboards containing thousands of nodes, this scheduling strategy can effectively prevent the main thread from being blocked by intensive rendering tasks, ensuring that the page always maintains a smooth interactive experience and a stable frame rate output.

[0098] In one embodiment, the rendering method may further include:

[0099] Obtain the original state data of the nested tree structure;

[0100] Traverse the tree-like nodes of the original state data, and for each leaf node or intermediate node that needs to be subscribed to independently, generate a unique hash key based on its path level and node attributes;

[0101] The nested objects in the original state data are expanded, and a flattened one-dimensional dictionary structure is constructed using the hash key as the key name and the corresponding node data as the key value to construct the state data set.

[0102] For each key-value pair in the one-dimensional dictionary structure, the application data proxy intercepts the data. When the node data is accessed or modified through the hash key, the corresponding dependency collection or change notification is triggered.

[0103] Specifically, in large-scale enterprise-level front-end applications, business data typically exists in the form of deeply nested tree structures, such as configuration objects or document models containing multiple levels of categories, sub-items, and attributes. Applying a data proxy mechanism directly to such nested structures not only incurs performance overhead due to the need to trigger proxy interceptors layer by layer for each access to deeper nodes, but also because of the nature of object references in languages ​​like JavaScript, even minor changes to the parent object can lead to updates to the entire subtree's references, rendering dependency checks based on reference equality ineffective.

[0104] To address this issue, this embodiment preprocesses the original state data by flattening it before establishing reverse dependencies. The system first obtains the original state data in a nested tree structure, then performs a depth-first or breadth-first traversal. During the traversal, for each leaf node or intermediate node requiring independent subscription, a unique hash key is generated based on its path level and node attributes. The nested objects in the original state data are expanded, using the hash key as the key name and the corresponding node data as the key value to construct a flattened one-dimensional dictionary structure, thus building the state data set. The application data proxy intercepts each key-value pair in the one-dimensional dictionary structure. When the node data is accessed or modified via the hash key, the corresponding dependency collection or change notification is triggered.

[0105] It should be understood that although this embodiment describes a method for generating hash keys based on path hierarchy and node attributes, other key generation strategies that can guarantee global uniqueness can also be adopted in other embodiments. For example, each node can be assigned a globally unique identifier issued by the server or generated by the client as a hash key, or a composite key can be generated by combining the business semantic label of the node with the index position. Regardless of the specific key generation rules or conversion timing used, as long as the nested tree data can be reduced to a one-dimensional index structure, and constant-time access and precise change notification of nodes at any depth can be achieved on this basis, it falls within the protection scope of this application. This embodiment provides an efficient and stable data foundation for the establishment of reverse dependency mapping through the above-mentioned state data flattening preprocessing mechanism, so that subsequent rendering scheduling interception and targeted local rendering can play a maximum role under the support of data access with O(1) complexity, which is especially suitable for heavy front-end application scenarios such as dynamic data dashboards and online document editors with thousands of nodes and complex data structures.

[0106] Corresponding to the above method embodiments, the present invention also discloses a rendering device for a front-end component.

[0107] See Figure 2 The present invention discloses a schematic diagram of a front-end component rendering device, the device comprising:

[0108] The read behavior acquisition unit 201 is used to acquire the read behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the read behavior.

[0109] Specifically, during the operation of the front-end application, the system does not rely on the parent-child hierarchy of components in the tree structure to pass state update notifications. Instead, it dynamically captures this data consumption behavior by monitoring the actual access operations of components to state data when executing rendering or initialization logic. For example, when a chart component reads the state identifier representing "real-time temperature" from the state data set during rendering, the system records the correspondence between the state identifier and the chart component instance. This establishment of a reverse dependency essentially transforms the implicit hierarchical coupling between state data and view components into an explicit point-to-point mapping graph. In this way, no matter how deeply a component is nested in the view tree, as long as it actually uses a certain state identifier, the system can establish a direct data-to-view index channel, providing a precise path for subsequent accurate updates and effectively avoiding the inefficient mechanism of blindly broadcasting updates based solely on the component tree structure.

[0110] The response unit 202 is used to intercept the default top-down rendering schedule of the front-end framework and block the virtual node comparison process of component nodes that do not depend on the target state identifier in response to a change in the target state identifier.

[0111] Specifically, when the target state identifier in the state data set changes, existing front-end frameworks typically trigger a top-down recursive update process starting from the root node or the nearest common ancestor node. This forces many components that do not use the data to regenerate virtual nodes and perform difference comparisons. This embodiment introduces interception logic into the framework's update scheduling mechanism, intervening before the default full or subtree update task is executed. Once a change event of the target state identifier is captured, the system immediately identifies which component nodes have not subscribed to the target state identifier in the reverse dependency relationship and actively blocks the regeneration and comparison process of virtual nodes of these unrelated nodes. Therefore, the propagation path of redundant computation is cut off at the scheduling level, ensuring that computing resources are not wasted on view branches unrelated to the current data change, thereby effectively eliminating the rendering waterfall effect.

[0112] The rendering unit 203 is used to determine the target component instance that depends on the target state identifier based on the reverse dependency relationship, and to trigger the target component instance to perform local rendering so as to skip the associated component nodes that have not undergone state change.

[0113] Specifically, after intercepting the default schedule and blocking irrelevant nodes, the system uses the constructed reverse dependency relationship as a query index to directly locate the set of all component instances that actually depend on the target state identifier. Subsequently, the system triggers a separate rendering update task for these target component instances, causing them to re-execute the rendering function to generate new virtual nodes and update the real DOM. During this process, even if the target component has parent, sibling, or other related components in the view tree, as long as these related components do not depend on the changed target state identifier, they will be completely skipped and will not participate in any form of re-rendering or comparison calculation.

[0114] In summary, the rendering device for front-end components provided by this invention establishes a reverse dependency relationship between state identifiers and instances of front-end components by acquiring the reading behavior of front-end components on state identifiers in the state data set. This ensures that the mapping between state data and view components does not depend on the hierarchical structure of the component tree, but directly points to the instance of the front-end component consuming the state using the state identifier as an index. Furthermore, when the target state identifier in the state data set changes, the device intercepts the default top-down rendering schedule of the front-end framework, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier. This prevents unrelated components from participating in the regeneration and difference comparison of virtual nodes during the update cycle. Moreover, by querying the reverse dependency relationship, the device determines the target component instance that depends on the target state identifier and triggers the target component instance to perform local rendering. This ensures that the update operation only applies to the target component instance that actually depends on the state, skipping all associated component nodes that have not undergone state changes. Therefore, this invention reduces the computational overhead of rendering updates from being related to the depth of the component tree and the total number of nodes to being related only to the number of components that actually depend on the changed state. This cuts off the propagation path of redundant computation and the rendering waterfall effect caused by the coupling of the state dependency structure and the component tree structure. It effectively avoids the main thread blocking, page frame drops and interaction response delays caused by irrelevant components participating in virtual node comparison, and improves the rendering performance and interaction smoothness of complex front-end applications in high-frequency data update scenarios.

[0115] In one embodiment, the read behavior acquisition unit 201 can be specifically used for:

[0116] During the initialization rendering phase of the front-end component, a data proxy mechanism is used to intercept the front-end component's reading operation of the state identifier;

[0117] Record the read state identifier and associate the state identifier with the instance of the front-end component to generate a reverse dependency mapping graph.

[0118] In one embodiment, the response unit 202 can be specifically used for:

[0119] An interceptor is mounted before the update scheduler in the front-end framework to capture change events of the target state identifier.

[0120] In response to the change event, the rendering state of component nodes that do not depend on the target state identifier is marked as skipped, or the component node is controlled to directly return to the cached historical virtual node, so as to block the regeneration and comparison of the virtual node of the component node.

[0121] In one embodiment, the rendering unit 203 can specifically be used for:

[0122] The local rendering tasks of the target component instance are pushed into the asynchronous task queue for batch processing.

[0123] In the next rendering frame, the local rendering task in the asynchronous task queue is directly triggered to execute the local rendering function of the target component instance.

[0124] In one embodiment, the rendering apparatus may further include:

[0125] The allocation unit is used to allocate a weak reference object to an instance of the front-end component when the front-end component is mounted, and store the weak reference object in the subscription set of the corresponding state identifier in the reverse dependency mapping graph.

[0126] The identification unit is used to traverse the reverse dependency mapping graph and identify the weak reference objects in the subscription set whose reference targets have been released by the garbage collection mechanism when the front-end component triggers the uninstallation lifecycle hook;

[0127] The deletion unit is used to remove invalid weak reference objects from the subscription set, and when the subscription set is empty, delete the key-value pair of the corresponding state identifier from the reverse dependency mapping graph and release the data proxy listening of the state identifier.

[0128] In one embodiment, the rendering apparatus may further include:

[0129] The state data acquisition unit is used to acquire the original state data of the nested tree structure.

[0130] The generation unit is used to traverse the tree nodes of the original state data and generate a unique hash key for each leaf node or intermediate node that needs to be subscribed to independently, based on its path level and node attributes.

[0131] A construction unit is used to expand the nested objects in the original state data, using the hash key as the key name and the corresponding node data as the key value, to construct a flattened one-dimensional dictionary structure to construct the state data set.

[0132] The triggering unit is used to intercept the application data proxy for each key-value pair in the one-dimensional dictionary structure, and to trigger the corresponding dependency collection or change notification when the node data is accessed or modified through the hash key.

[0133] In one embodiment, the response unit 202 can be specifically used for:

[0134] During the initialization phase of the front-end component, a custom dependency tracking hook is injected through a composite function. The dependency tracking hook is used to open the dependency collection context before the original rendering function is executed and to close the dependency collection context after execution.

[0135] The front-end component is wrapped with a higher-order wrapper component, and the update command issued by the update scheduler of the front-end framework is intercepted in the rendering logic of the higher-order wrapper component.

[0136] When the update instruction is received, the higher-order wrapper component checks whether the state identifier on which the front-end component depends has changed. If it has not changed, it directly returns the historical virtual node cached from the last rendering.

[0137] In one embodiment, the rendering unit 203 can also be used for:

[0138] Bind the local rendering task in the asynchronous task queue to the browser's request animation frame callback;

[0139] Within each rendering frame triggered by the request animation frame callback, the local rendering task merged and batched in the asynchronous task queue is executed.

[0140] It should be noted that for the specific working principles of each component in the device embodiment, please refer to the corresponding section of the method embodiment, which will not be repeated here.

[0141] Corresponding to the above embodiments, such as Figure 3 As shown, the present invention also provides a schematic diagram of the structure of an electronic device, which may include: a processor 1 and a memory 2;

[0142] The processor 1 and memory 2 communicate with each other via communication bus 3.

[0143] Processor 1, for executing at least one instruction;

[0144] Memory 2 is used to store at least one instruction;

[0145] Processor 1 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0146] Memory 2 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0147] In this embodiment, processor 1 executes at least one instruction to implement the steps shown in the rendering method embodiment for the front-end component.

[0148] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0149] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0150] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for rendering a front-end component, characterized in that, include: Obtain the reading behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the reading behavior; In response to a change in the target state identifier in the state data set, the default top-down rendering schedule of the front-end framework is intercepted, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier. Based on the reverse dependency, a target component instance that depends on the target state identifier is determined, and the target component instance is triggered to perform partial rendering to skip associated component nodes that have not undergone state changes.

2. The rendering method according to claim 1, characterized in that, The step of obtaining the front-end component's reading behavior of state identifiers in the state data set, and establishing a reverse dependency relationship between the state identifiers and instances of the front-end component based on the reading behavior, includes: During the initialization rendering phase of the front-end component, a data proxy mechanism is used to intercept the front-end component's reading operation of the state identifier; Record the read state identifier and associate the state identifier with the instance of the front-end component to generate a reverse dependency mapping graph.

3. The rendering method according to claim 1, characterized in that, The interception of the front-end framework's default top-down rendering schedule, blocking the virtual node comparison process of component nodes that do not depend on the target state identifier, includes: An interceptor is mounted before the update scheduler in the front-end framework to capture change events of the target state identifier. In response to the change event, the rendering state of component nodes that do not depend on the target state identifier is marked as skipped, or the component node is controlled to directly return to the cached historical virtual node, so as to block the regeneration and comparison of the virtual node of the component node.

4. The rendering method according to claim 1, characterized in that, The step of triggering the target component instance to perform partial rendering includes: The local rendering tasks of the target component instance are pushed into the asynchronous task queue for batch processing. In the next rendering frame, the local rendering task in the asynchronous task queue is directly triggered to execute the local rendering function of the target component instance.

5. The rendering method according to claim 2, characterized in that, The rendering method also includes: When the front-end component is mounted, a weak reference object is allocated to the instance of the front-end component, and the weak reference object is stored in the subscription set of the corresponding state identifier in the reverse dependency mapping graph; When the front-end component triggers the uninstallation lifecycle hook, the reverse dependency mapping graph is traversed to identify the weak reference objects in the subscription set whose reference targets have been released by the garbage collection mechanism; Remove invalid weak reference objects from the subscription set, and when the subscription set is empty, delete the key-value pair of the corresponding state identifier from the reverse dependency mapping graph, and unblock the data proxy listening of the state identifier.

6. The rendering method according to claim 1, characterized in that, The rendering method also includes: Obtain the original state data of the nested tree structure; Traverse the tree nodes of the original state data, and for each leaf node or intermediate node that needs to be subscribed to independently, generate a unique hash key based on its path level and node attributes; The nested objects in the original state data are expanded, and a flattened one-dimensional dictionary structure is constructed using the hash key as the key name and the corresponding node data as the key value to construct the state data set. For each key-value pair in the one-dimensional dictionary structure, the application data proxy intercepts the data. When the node data is accessed or modified through the hash key, the corresponding dependency collection or change notification is triggered.

7. The rendering method according to claim 3, characterized in that, The interceptor mounted before the update scheduler in the front-end framework includes: During the initialization phase of the front-end component, a custom dependency tracking hook is injected through a composite function. The dependency tracking hook is used to open the dependency collection context before the original rendering function is executed and to close the dependency collection context after execution. The front-end component is wrapped with a higher-order wrapper component, and the update command issued by the update scheduler of the front-end framework is intercepted in the rendering logic of the higher-order wrapper component. When the update instruction is received, the higher-order wrapper component checks whether the state identifier on which the front-end component depends has changed. If it has not changed, it directly returns the historical virtual node cached from the last rendering.

8. The rendering method according to claim 4, characterized in that, The step of directly triggering the local rendering task in the asynchronous task queue in the next rendering frame includes: Bind the local rendering task in the asynchronous task queue to the browser's request animation frame callback; Within each rendering frame triggered by the request animation frame callback, the local rendering task merged and batched in the asynchronous task queue is executed.

9. A rendering device for a front-end component, characterized in that, include: The read behavior acquisition unit is used to acquire the read behavior of the front-end component on the state identifier in the state data set, and establish a reverse dependency relationship between the state identifier and the instance of the front-end component based on the read behavior. The response unit is used to respond to a change in the target state identifier in the state data set, intercept the default top-down rendering schedule of the front-end framework, and block the virtual node comparison process of component nodes that do not depend on the target state identifier. The rendering unit is used to determine the target component instance that depends on the target state identifier based on the reverse dependency relationship, and to trigger the target component instance to perform local rendering to skip the associated component nodes that have not undergone state change.

10. An electronic device, characterized in that, The electronic device includes: a memory and a processor; The memory is used to store at least one instruction; The processor is configured to execute the at least one instruction to implement the rendering method of the front-end component as described in any one of claims 1 to 8.

Images