A method and apparatus for generating a multi-dimensional tree table control

Abstract

This invention discloses a method and apparatus for generating a multi-dimensional tree-shaped table control, relating to the field of data processing. The method includes: obtaining a flattened raw data array, an expandable dimension array, a maximum dimension level, and a configuration object from the backend; initializing the core data structure; traversing the raw data and all nodes, finding the parent node and establishing relationships to construct a dual-channel tree structure; generating and rendering a table view based on the constructed tree structure; and responding to user interaction by dynamically expanding and collapsing table nodes through maintaining inter-row references and collapse states. This invention separates the natural hierarchy and interactive expansion hierarchy of data through a dual-channel tree structure and utilizes path key mapping and a local state update mechanism to solve the problems of hierarchical chaos, low rendering efficiency, and slow interactive response in traditional tree tables during multi-dimensional data analysis. It achieves efficient and flexible multi-dimensional data display and interaction, suitable for enterprise-level data analysis scenarios.

Description

Technical Field

[0001] This invention relates to the field of data processing, and specifically to a method and apparatus for generating a multi-dimensional tree table control. Background Technology

[0002] In the field of big data analytics and business intelligence (BI), front-end tree-structured table controls are core components for displaying multi-dimensional data with hierarchical relationships, and are widely used in scenarios such as organizational structure management, product classification analysis, and project task tracking. This type of data typically has two key characteristics: first, it is multi-dimensional (e.g., involving multiple analytical perspectives such as departments, employees, and products); second, there are natural hierarchical relationships within each dimension. An ideal control should support users in independently expanding, drilling down, and collapsing different dimension paths within the same view to achieve efficient cross-analysis.

[0003] However, existing tree-structured table solutions have significant limitations in achieving the above objectives, mainly in three aspects: data construction, interaction performance, and scalability.

[0004] First, there are flaws in the data model and construction logic. Most solutions only support expansion along a single preset dimension path, failing to achieve independent and synchronous expansion and collapse of multiple dimension fields. This forces users to perform multiple page jumps or view switches during analysis, disrupting the continuity of the analysis process. Furthermore, to achieve a tree structure, one common approach is for the backend to return deeply nested data, resulting in redundant transmission and a heavy parsing burden on the frontend; another common approach is for the frontend to recursively construct the structure based on flat data, but this lacks efficient node location and association mechanisms (such as relying solely on recursive traversal to establish parent-child relationships), leading to slow construction speeds and an inability to support fast parent node queries.

[0005] Secondly, there are bottlenecks in interactive performance and user experience. Due to limitations in the underlying data model and rendering mechanism, the expand / collapse interaction of existing controls is slow. A common reason is that each interactive operation (such as collapsing a node) may require retracing or recalculating the entire (or part of) tree structure to determine which child nodes need to be hidden or shown. When the tree structure is large or deeply nested, this traversal overhead will lead to significant operation delays. At the same time, large-scale dynamic insertion and deletion of DOM elements can easily trigger frequent browser reflow and repaint, further exacerbating performance degradation.

[0006] Furthermore, the design lacks in data association and architectural scalability. Many solutions have indirect or loose connections between tree nodes and the original business data, making it complex and error-prone to synchronously update the underlying data source after editing data in the table. Additionally, existing solutions are often deeply coupled with specific UI frameworks or third-party plugins, resulting in fixed display formats and interactive behaviors that are difficult to flexibly adapt to enterprise-level personalized needs such as custom hierarchical indentation and dynamic column rendering. Regarding loading strategies, a dilemma often arises: full loading causes initial rendering lag when dealing with large amounts of data; while paginated loading disrupts the continuity of the tree structure, impacting user experience.

[0007] In summary, existing technologies fail to provide a method for generating tree-structured table controls that efficiently construct from flat data, support multi-dimensional independent drill-down, and possess high-performance expand / collapse interactive capabilities. Therefore, an innovative technical solution is urgently needed to systematically address the core issues of data construction efficiency, real-time interactivity, and architectural flexibility. Summary of the Invention

[0008] The purpose of this invention is to provide a method and apparatus for generating multi-dimensional tree-structured table controls, aiming to overcome the problems of existing tree-structured tables that only support single-dimensional expansion, have low data processing efficiency, delayed interactive response, and poor scalability. Based on flattened raw data, this invention constructs a dual-channel tree structure with both "natural hierarchies" and "expandable hierarchies," supporting independent and synchronous expansion and collapse of multi-dimensional fields. It also integrates unique path key identifiers, parent node lookup caching, and inter-row reference folding counting mechanisms to achieve rapid construction of node relationships and high-performance dynamic interaction, ultimately providing users with an efficient, flexible, and responsive multi-dimensional data analysis tool.

[0009] Firstly, the present invention provides a method for generating a multi-dimensional tree table control, and the technical solution adopted to solve the above-mentioned technical problems is as follows:

[0010] Retrieve the raw data array, expandable dimension name array, maximum dimension level, and configuration object sent by the backend. The raw data array is a flat data array, with each row containing multiple dimension fields and corresponding configuration information. The configuration object is used to control the building and interaction behavior.

[0011] Initialize the data structure, which includes: a root node array, an array of all node information, a path key to node information mapping, an expanded child node mapping, and an expanded dimension set;

[0012] The process of traversing data to construct nodes includes: traversing each row of the flattened data array, extracting all dimensions and creating a node for the last dimension of each row, saving the original data array row index of the row as the original data row index of the node, generating a parent path key, generating a complete path key based on the parent path key as the unique identifier of the node, and finally storing the created node information into a path key to node information mapping with the path key as the key and an array of all node information.

[0013] By traversing all nodes again, the parent node is quickly found and the parent-child relationship is established in the mapping from path key to node information according to the two types of nodes constructed. Finally, all nodes form a dual-channel tree structure containing natural hierarchy and expandable hierarchy according to their type and path. The two types of nodes are ordinary nodes and expandable nodes.

[0014] Clean up temporary data and return the core result object of the tree structure;

[0015] Based on the returned tree structure core result object, traverse the recursive root node array, construct row data, and traverse the row data to render the table.

[0016] Users can dynamically expand or collapse the rendered table.

[0017] Optionally, the configuration object includes at least one configuration parameter, which indicates whether lazy loading mode is enabled to control the loading behavior of expandable child nodes.

[0018] Optionally, the traversal of data to construct nodes further includes: processing dimensionless data, specifically: when traversing the original data array, if the values ​​of all dimension fields in the currently traversed original data row are empty, then a root node with a dimension name of a predefined root identifier is created, and the created root node is directly added to the root node array.

[0019] Optionally, the step of generating a parent path key and then generating a complete path key based on the parent path key as a unique identifier for the node specifically involves:

[0020] From the extracted dimension fields, select the ID corresponding to the last dimension as the current dimension ID;

[0021] The IDs of all dimensions preceding the last dimension are concatenated to generate the parent path key;

[0022] The parent path key is concatenated with the current dimension ID to generate the complete path key;

[0023] If there is no dimension preceding the last dimension, the parent path key is empty, and the complete path key is the current dimension ID.

[0024] Optionally, the types of nodes constructed are divided into: ordinary nodes and expandable nodes; among them,

[0025] The ordinary node is used to represent the natural hierarchical relationship formed according to the order of the dimension fields of the original data, wherein the ordinary node corresponding to the next dimension field is a child node of the ordinary node corresponding to the previous dimension field.

[0026] The expandable node is used to represent a cross-level relationship that can be dynamically expanded or collapsed based on the parent node identifier;

[0027] The expandable node is associated with attributes used to control its expandable / collapsed state.

[0028] Optionally, the step of traversing all nodes again and quickly finding the parent node and establishing the parent-child relationship based on its parent path key in the mapping from path key to node information according to the two types of nodes constructed includes finding the parent node through a caching mechanism, specifically:

[0029] When looking up the parent node of the current node, if the node type is a normal node, the corresponding cache key is generated based on its parent path key; if the node type is an expandable node, the corresponding cache key is generated based on its parent path key and parent node ID, or the corresponding cache key is generated based on its parent path key.

[0030] The parent node lookup cache is queried based on the cache key generated for the current node; if the cache is hit, the cached parent node information is directly obtained; if the cache is not hit, a search is performed from the mapping of the path key to the node information, and the search result is stored in the parent node lookup cache.

[0031] Further optionally, the step of quickly finding the parent node and establishing the parent-child relationship based on the parent path key in the mapping from path key to node information according to the two types of nodes constructed is as follows:

[0032] For expandable nodes, if the current expandable node has a valid parent node ID, the parent node is first located by combining the parent path key of the current expandable node with the parent node ID to form a lookup key. If the parent node is found by the lookup key, differentiated processing is performed according to the configured loading mode. If the parent node is not found by the lookup key, the parent node is searched by the parent path key of the current expandable node. If the parent node is found, the current expandable node is attached to the parent node's child node array. If the parent node is not found, the current expandable node is demoted to the root node and added to the root node array.

[0033] For a regular node, if the current regular node has no parent path key, then the current regular node is added to the root node array as the root node; if the current regular node has a parent path key, then the corresponding parent node is searched. If the search is successful, the current regular node is mounted to the parent node's child node array; if the search fails, then the current regular node is added to the root node array as the root node.

[0034] Further optionally, if the parent node is found using the lookup key, then differentiated processing is performed according to the configured loading mode, specifically:

[0035] If lazy loading mode is enabled, the node is temporarily stored in the expanded child node mapping;

[0036] If lazy loading is not enabled, it is directly attached to the expanded child node array of the parent node, and the drill-down level of the node is set to the drill-down level of the parent node plus one.

[0037] Optionally, based on the returned tree structure core result object, the recursive root node array is traversed to construct row data, and the table is rendered by traversing the row data. Specifically:

[0038] Traverse the root node array and recursively visit the child nodes of each node in a depth-first manner to generate a flat table row data set; wherein, during the traversal, expandable child nodes that are in a collapsed state are not visited.

[0039] When traversing each node, the node level is determined based on its full path key, and the corresponding data is extracted from the original data array according to its original data row index to construct a table row and add it to the table row data set;

[0040] Based on the set of table row data, a multi-dimensional tree table with a hierarchical structure is rendered and generated.

[0041] Optionally, the user can dynamically expand or collapse the rendered table, specifically:

[0042] In response to the user's first expansion operation on the expandable node, the corresponding expanded child node data is obtained from the expanded child node mapping according to the complete path key of the node, the row data to be inserted is generated, and it is inserted into the table row data set after the corresponding row of the node;

[0043] After insertion, establish inter-line references, point the next line reference of the expanded line to its original next line, and set the expanded state flag of the expanded line to a value that indicates the expanded state;

[0044] In response to the user's collapse operation on the expanded node, starting from the expanded row, traverse to the target row according to the next row reference, increment the collapse count of each traversed row by one, and set the expanded state flag of the expanded row to a value indicating the collapsed state.

[0045] In response to the user's operation of expanding a collapsed node again, starting from the expanded row, traverse to the target row according to the next row reference, decrement the collapse count of each row traversed, and set the expanded state flag of the expanded row to a value indicating the expanded state.

[0046] The display or hiding of a row is determined by its fold count.

[0047] Further, optionally, the fold count is used to control the display or hiding state of the row:

[0048] A row is displayed in the table when its collapse count is 0; it is hidden in the table when its collapse count is greater than 0.

[0049] Secondly, the present invention provides a multi-dimensional tree table control generation device, and the technical solution adopted to solve the above-mentioned technical problems is as follows:

[0050] A multi-dimensional tree table control generation device, comprising:

[0051] The data acquisition module is configured to acquire the raw data array, expandable dimension name array, maximum dimension level, and configuration object sent by the backend. The raw data array is a flat data array, with each row containing multiple dimension fields and corresponding configuration information. The configuration object is used to control the building and interaction behavior.

[0052] The structure initialization module is configured to initialize the data structure, which includes: a root node array, an array of all node information, a path key to node information mapping, an expanded child node mapping, and an expandable dimension set;

[0053] The node building module is configured to traverse data to build nodes, including: traversing each row of the flattened data array, extracting all dimensions and creating a node for the last dimension of each row, saving the original data array row index of the row as the original data row index of the node, generating a parent path key, generating a complete path key based on the parent path key as the unique identifier of the node, and finally storing the created node information into a path key to node information mapping with the path key as the key and an array of all node information.

[0054] The relationship establishment module is configured to quickly find the parent node and establish the parent-child relationship by traversing all nodes again and according to the two types of nodes constructed, based on their parent path keys in the mapping from path keys to node information. Finally, all nodes form a dual-channel tree structure containing natural hierarchy and expandable hierarchy according to their type and path. The two types of nodes are ordinary nodes and expandable nodes.

[0055] The data cleaning and return module is configured to clean up temporary data and return the core result object of the tree structure.

[0056] The table rendering module is configured to traverse the recursive root node array based on the returned tree structure core result object, construct row data, and then traverse the row data to render the table.

[0057] The interactive control module is configured to support users in dynamically expanding or collapsing the rendered table.

[0058] Compared with the prior art, the multi-dimensional tree table control generation method and apparatus of the present invention have the following advantages:

[0059] 1. Supports multi-dimensional independent expansion and interaction, breaking the limitations of single-dimensional display. By constructing a dual-channel tree structure with both ordinary nodes (corresponding to natural levels) and expandable nodes (corresponding to drill-down levels), it enables synchronous, independent expansion and collapse operations of multiple dimension fields. Users can complete cross-dimensional data analysis in the same view without page jumps or view switching, improving the efficiency of viewing complex data and the continuity of analysis, and breaking through the limitation of traditional tree tables that can only expand along a single preset dimension path.

[0060] 2. Dual optimization of data processing efficiency and transmission performance. A method based on flattened raw data to construct a tree structure is adopted, reducing transmission redundancy caused by nested data structures from the source, making it particularly suitable for large data volume scenarios. Innovatively, a complete path key is used to uniquely identify nodes, combined with a parent node lookup caching mechanism, enabling rapid establishment of node relationships and O(1) time complexity lookup of parent nodes. This replaces the inefficient recursive traversal in traditional solutions, significantly improving the construction speed and overall performance of the tree structure.

[0061] 3. Real-time and efficient interactive response, significantly reducing rendering performance overhead. The introduction of an "interline reference association and collapse counting" expansion / collapse control mechanism ensures that regardless of the depth of the tree structure, expansion or collapse operations only require adjusting the count and switching the state of local rows, without needing to retrace or recalculate the entire tree structure, greatly reducing interaction latency. This mechanism, combined with an on-demand lazy loading mode (expandable child nodes are only loaded when first expanded), effectively avoids frequent DOM reflow and repaint, ensuring a smooth and immediate user interaction experience while maintaining the integrity of the tree structure.

[0062] 4. The data is tightly and directly linked, and the system architecture is flexible and highly scalable. Each tree node retains an index pointing to the original data row, allowing editing operations in the front-end table to be directly mapped and synchronously updated to the underlying business data source, simplifying the data maintenance process and reducing the risk of data inconsistency. Furthermore, the core solution does not rely on a specific UI framework or third-party plugins, achieving decoupling between the data model and the presentation layer. This easily supports diverse enterprise-level customization needs such as custom hierarchical indentation and dynamic column rendering, demonstrating excellent architectural flexibility and scalability.

[0063] 5. The anomaly handling mechanism is robust and the operation is stable and reliable. To address potential anomalies during data construction, such as rows of data without dimensions or parent node lookup failures, fallback rules such as creating root nodes and demoting nodes to root nodes have been designed to ensure the normal construction of the tree structure under various data conditions.

[0064] 6. Balancing functional completeness and high performance to meet enterprise-level application requirements. While successfully implementing complex functions such as multi-dimensional synchronous expansion, hierarchical display, and on-demand drill-down, this invention ensures high-performance operation of the system under large data volumes through multiple technical means, including path keys, caching optimization, and lazy loading. The final solution achieves an excellent balance between rich functionality, real-time interactivity, and system resource consumption, fully meeting the high standards of modern business intelligence (BI) and other enterprise-level data analysis applications. Attached Figure Description

[0065] Appendix Figure 1 This is a flowchart illustrating the overall process of generating a multi-dimensional tree-shaped table control.

[0066] Appendix Figure 2 This is a flowchart illustrating the path key generation process for a multi-dimensional tree-shaped table control generation method.

[0067] Appendix Figure 3 It is a flowchart for dynamically expanding or collapsing an already rendered table.

[0068] Appendix Figure 4 This is a schematic diagram of the structure of a multi-dimensional tree table control generation device. Detailed Implementation

[0069] To make the technical solution, the technical problem solved, and the technical effect of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments.

[0070] Example 1: As Figure 1 As shown, this embodiment proposes a method for generating a multi-dimensional tree table control, including:

[0071] S1: Obtain build parameters and raw data

[0072] This step aims to receive and parse all the basic data and control parameters required to construct a multi-dimensional tree table, providing data and rule support for subsequent tree structure construction, rendering, and interactive functions. Specifically, the input information obtained includes the following four aspects:

[0073] 1.1 Obtaining the original data array

[0074] The system retrieves a raw data array (data) from the backend service. This array uses a flat data structure, with each row representing an independent business data record. This flat design avoids data nesting, significantly reduces network transmission volume, and facilitates efficient processing by the frontend. Each record contains multiple dimension fields, corresponding dimension configuration objects, and business metric data. An example is shown below:

[0075] const originTableDatas=[

[0076] {dim1:"Marketing Department",

[0077] dim1_config:{id:"1001",name:"Organizational Structure",parentID:"-2"},

[0078] dim2:"Employee A",

[0079] dim2_config:{id:"1014",name:"Employee",parentID:"1001"},

[0080] dim3:"Product X",

[0081] dim3_config:{id:"64eef93a9271e20001a1da9e",name:"Product Category"},

[0082] agg_year_revenue:150000,

[0083] agg_year_revenue_fmt:"150,000"},

[0084] {

[0085] dim1:"East China Region",

[0086] dim1_config:{id:"RegionEast",name:"East China Region",parentID:"-2"},

[0087] dim2:"Shanghai",

[0088] dim2_config: {id: "CitySh", name: "Shanghai City", parentID: "RegionEast"},

[0089] dim3: "Product A",

[0090] dim3_config: {id: "ProdA", name: "Product A"},

[0091] revenue: 150000,

[0092] revenue_fmt: "150,000"},

[0093] / / ... More data rows];

[0094] Data description:

[0095] Dimension fields (such as dim1, dim2, dim3): Represent different analysis perspectives of the data, and their appearance order usually implies the default natural hierarchical relationship (for example, dim1 can be the parent of dim2).

[0096] Dimension configuration object (such as dim1_config): Contains the core metadata of the dimension. id is the unique identifier; parentID is used to establish the parent-child association of the expandable dimension (drill down), where special values (such as "-2") indicate that the node has no parent node and is the root node; name is the dimension name.

[0097] Metric fields (such as agg_year_revenue, revenue): Specific business numerical data that needs to be displayed and analyzed.

[0098] 1.2 Obtain an array of expandable dimension names

[0099] The system obtains an array of dimension names (drillableDims) to clearly specify which dimensions support users to perform interactive expand (drill down) and collapse operations. The elements of this array are the names of the dimension fields in the original data.

[0100] const drillableDims = ["dim1", "dim2"];

[0101] The above configuration indicates that the nodes corresponding to dim1 (e.g., "Organizational Structure" / "East China Region") and dim2 (e.g., "Employees" / "Provinces and Cities") are defined as "expandable nodes," which users can click to drill down. Dimensions not in the array (e.g., dim3 in this example) are considered "ordinary nodes," which only participate in forming a static hierarchical structure and do not have independent expandable interactive functions.

[0102] 1.3 Obtaining the maximum dimension level

[0103] The system obtains an integer value maxDimension to limit the maximum dimension depth that needs to be built and processed for this table display, preventing display chaos due to too many dimensions and providing display flexibility.

[0104] const maxDimension=3;

[0105] This configuration means that even if the original data may contain more dimensional fields, only the first three dimensions (dim1, dim2, dim3) are processed to build the tree structure.

[0106] 1.4 Obtaining the Configuration Object

[0107] The system obtains a configuration object (options) to control the building strategy and interaction behavior of the tree structure. This object contains at least one core parameter, lazyLoadDrillChildren, which enables or disables lazy loading mode to control the loading behavior of expandable child nodes. This configuration object is key to achieving performance optimization and flexible switching of interaction modes.

[0108] const options={lazyLoadDrillChildren:true / / Enable lazy loading mode}

[0109] rootNodeName:"Total" / / Optional, used as the display name of the root node when there is no dimension data};

[0110] Detailed explanation of lazy loading mode:

[0111] Enable lazy loading mode (lazyLoadDrillChildren:true): In this mode, the child node data of all expandable nodes is not directly mounted to the tree structure during initialization, but is temporarily stored in a separate mapping table (drillChildrenMap). Its child nodes are only dynamically loaded and rendered when the user first clicks to expand the node. This mode greatly optimizes initialization performance and memory usage, and is especially suitable for scenarios with a large amount of child node data.

[0112] Disable lazy loading mode (immediate loading) (lazyLoadDrillChildren:false): All expandable child nodes will be directly mounted to the parent node's drillChildren array (i.e., the expandable child node array) during the tree construction phase, achieving full initial loading and ensuring no data loading delay during the first expand operation.

[0113] This step completes all input preparations before the system is built. The flattened raw data array ensures efficient transmission and parsing; the expandable dimensional array and the maximum dimensional level define the shape and interaction boundaries of the tree structure; and the configuration object provides the core performance optimization strategy (lazy loading). These parameters together form a solid foundation for the subsequent processes.

[0114] S2: Initialize core data structures

[0115] This step is executed after obtaining all input parameters (S1). Its core purpose is to create and initialize the various basic data containers required for building a multi-dimensional tree table. These containers establish an efficient and clear temporary "workbench" in memory, providing structured support for subsequent node creation, rapid establishment of parent-child relationships, lazy loading storage, and interactive control. Specifically, the following five core data structures are initialized:

[0116] 2.1 Root node array (tree):

[0117] Function: Serves as the root container and sole entry point for the final constructed multi-dimensional tree structure. All nodes at the top level of the tree (including nodes without parent paths, degraded nodes where finding a parent failed, and special root nodes created for non-dimensional data) will be collected in this array. It is the starting point for subsequent traversal to generate table row data and for table rendering.

[0118] Initialization method: Create an empty array.

[0119] Code example: const tree=[];

[0120] Final form: Array <node>, where Node is a node object.

[0121] 2.2 Array of all node information (allNodes):

[0122] Purpose: Acts as a temporary, centralized workspace during the tree construction phase. It stores a complete information tuple for all created nodes, typically including the node object itself, its parentPathKey, fullPathKey, and an identifier indicating whether it is expandable (isDrillable). The main purpose of this array is to provide a unified, linear traversal source for the subsequent "establishing parent-child relationships" phase, avoiding repeated traversals of the original data array.

[0123] Initialization method: Create an empty array.

[0124] Code example: const allNodes=[]; / / Format: [{node,parentPathKey,fullPathKey,isDrillable},…]

[0125] Lifecycle: This structure is temporary storage. Once the parent-child relationships between nodes are fully established, the memory it occupies will be released, reflecting optimized management of memory resources.

[0126] 2.3 Mapping of path keys to node information (nodesByPath):

[0127] Function: This is the core of the high-performance fast lookup dictionary in this scheme. The mapping is constructed using the unique identifier of each node—the full path key (fullPathKey)—as the key and the corresponding node object as the value. Its core value lies in achieving O(1) time complexity for finding the parent node. When it is necessary to determine the parent node of a node, the algorithm only needs to calculate the expected path key of the parent node according to the rules, and then directly access this mapping to obtain the parent node object, completely eliminating the time-consuming recursive or loop traversal search in traditional schemes, greatly improving the construction speed of the tree structure.

[0128] Initialization method: Create an empty Map object.

[0129] Code example: `const nodesByPath = new Map();` / / Key: `fullPathKey` (String), Value: Node object

[0130] 2.4 Expanding the child node map (drillChildrenMap):

[0131] Purpose: A temporary storage area for child nodes specifically designed for lazy loading. When the `lazyLoadDrillChildren` parameter in the configuration object is `true`, all child nodes identified as expandable nodes (where `isDrillable` is `true`) will not be directly attached to their parent nodes during initialization. Instead, the system stores an array of all expandable child nodes belonging to that parent node in this mapping, using the parent node's complete path key as the key and the array as the value. When a user triggers the first expand operation on a node in the front-end interface, the system retrieves the corresponding array of child nodes from this mapping based on the node's path key for dynamic loading and rendering. This mechanism delays the loading of a large number of potential child node data and the overhead of DOM rendering until the actual need, significantly optimizing the initial loading performance and memory usage of the table.

[0132] Initialization method: Create an empty Map object.

[0133] Code example: `const drillChildrenMap = new Map();` / / Key: Parent node `fullPathKey` (String), Value: Array of child nodes. <node>)

[0134] 2.5 DrillableDimsSet:

[0135] Purpose: An auxiliary query set for efficiently determining node types. It is derived from the array of expandable dimension names (drillableDims) in the input parameters. During the process of traversing data rows and creating node objects, it is necessary to frequently check whether the currently processed dimension supports expandable interaction. Using this set for this check (drillableDimsSet.has(dimName)) has a time complexity of O(1), which is significantly more efficient than sequentially searching in the original array (O(n)).

[0136] Initialization method: Convert the drillableDims array into a Set collection.

[0137] Code example:

[0138] const drillableDims=["dim1","dim2"]; / / Input from step S1

[0139] const drillableDimsSet=newSet(drillableDims);

[0140] Example code snippets and collaboration relationships:

[0141] The following illustrates the typical implementation framework of steps S1 and S2 in the core method createDrillableTree, and clarifies the collaborative logic between data structures:

[0142] function createDrillableTree(data, drillableDims, maxDimension, options={}){ / / S1&S2: Receive parameters and initialize core data structures

[0143] const{lazyLoadDrillChildren=true}=options; / / Read lazy loading configuration (S1.4)

[0144] const tree=[]; / / 1. Root node array: the "display shelf" of the final product

[0145] const allNodes=[]; / / 2. Array of all node information: a "list of contents" during the build phase

[0146] const nodesByPath = new Map(); / / 3. Path key-node mapping: O(1) lookup of the "part index table"

[0147] const drillChildrenMap = new Map(); / / 4. Expand child node mappings: lazy-loaded "temporary storage area for parts to be assembled"

[0148] const drillableDimsSet = new Set(drillableDims); / / 5. Expandable Dimensional Set: An "Assembly Instruction Table" for Quick Decision-Making

[0149] / / …Subsequent steps (S3 / S4): Based on the above structure, traverse the data, build nodes, and establish relationships.

[0150] Data structure collaborative workflow and advantages:

[0151] During the construction phase: When traversing the original data, the information of the created nodes is stored in allNodes, and the mapping relationship between their fullPathKey and the node objects is recorded in nodesByPath, paving the way for fast lookups later. The node type is determined based on drillableDimsSet; if it is an expandable node with lazy loading enabled, it is temporarily stored in drillChildrenMap according to its parent path key.

[0152] Relationship establishment phase: Traverse allNodes and use nodesByPath to instantly find the parent node. The node type distinguished by drillableDimsSet determines whether it is added to the children array as a regular child node or processed accordingly based on the lazyLoadDrillChildren configuration (immediately added to drillChildren or temporarily stored in drillChildrenMap).

[0153] During the interaction phase: When the user triggers an expand operation, if lazy loading mode is used, child nodes are loaded on demand through drillChildrenMap. The final tree array serves as the root of the complete tree structure, driving the rendering and display of the table.

[0154] Through this systematic data structure initialization and parameter configuration, a data processing framework with clearly defined responsibilities and efficient collaboration is constructed. This design solves the problems of low construction efficiency, high memory consumption, and poor scalability caused by chaotic data structures in existing technologies. It lays a solid technical foundation for smoothly and flexibly transforming flat data into complex, multi-dimensional, interactive tree tables, and achieves a flexible balance between performance and user experience by controlling the lazyLoadDrillChildren parameter.

[0155] S3: Traverse the original data and construct nodes

[0156] This step (S3) is one of the core steps in constructing the tree structure. Its purpose is to traverse the original flattened data, create a node object with complete attributes for each row of data, and generate a unique identifier (path key) and data anchor (row index) for it, providing a data foundation for establishing subsequent parent-child relationships. The specific implementation process is as follows:

[0157] 3.1 Traversing the Original Data and Extracting Dimensions

[0158] The system begins by sequentially traversing each row in the original data array (originTableDatas). For the current row (indexed as rowIndex), based on the maximum dimension level (maxDimension), it extracts all valid dimension fields and their configuration objects, forming a dimension list (dims). According to the agreement with the backend interface, each dimension field must have a valid value and a non-empty configuration object. The system checks each dimension sequentially (e.g., dim1, dim1_config; dim2, dim2_config…), adding it to the list only if both the dimension value and configuration object are valid. A valid dimension typically includes a field value (e.g., "Marketing Department") and a configuration object (e.g., {id:"1001", name:"Organizational Structure", parentID:"-2"}).

[0159] 3.2 Handling Dimensionless Data (Boundary Cases)

[0160] During the traversal, if the system determines that the values ​​of all dimension fields in the current traversed original data row are empty (i.e., the values ​​of all dimension fields such as dim1, dim2...dimN are null, undefined, or empty strings, or their corresponding config objects are invalid), this boundary processing procedure is triggered.

[0161] At this point, the system will create a root node with a dimension name that is a predefined root identifier. The "predefined root identifier" is preferably obtained from the rootNodeName parameter of the configuration object (e.g., rootNodeName:"Total"). If not specified, the default identifier (e.g., "Root Node") will be used.

[0162] The core attributes of this special root node are set according to standardized rules:

[0163] dimName: Set to the predefined root identifier mentioned above (e.g., "Total").

[0164] dimId: Set to a predefined unique identifier (such as "root_default" or "-1").

[0165] dimValue: Set to the same display value as dimName.

[0166] level: Set to 1, representing the top-level root node level (or can be set to 0 according to the overall hierarchy design).

[0167] rowIndex: Retains the index of the current dimensionless data row in the original data array to maintain the association with the original data.

[0168] _fullPathKey: A unique path key generated based on dimId (e.g., "root_default").

[0169] children: Initialized as an empty array, used for natural child nodes that may be attached later.

[0170] isDrillable: Setting this to false will prevent it from being treated as an expandable node by default.

[0171] Once created, the root node is immediately added to the root node array (tree). This mechanism ensures that the tree construction process can continue even when faced with irregular, raw data rows that completely lack dimensional information, assigning them a logically reasonable display position, thus significantly enhancing the robustness and fault tolerance of the entire method.

[0172] 3.3 Determine the target dimension and create basic node information

[0173] For rows containing valid dimensions, the core of this step is to create a node for its last dimension. Specifically:

[0174] To obtain the target dimension: Take the last element from the dimension list (dims) as the target dimension targetDim, i.e., targetDim = dims[dims.length - 1]. The last dimension is chosen because it represents the "leaf" or the finest-grained information of the row of data in the multi-dimensional path.

[0175] Build the basic attributes of the node:

[0176] dimName: The name of the target dimension (e.g., "dim3").

[0177] dimId: A unique ID for the target dimension, taken from targetDim.config.id.

[0178] dimValue: The displayed value for the target dimension, i.e., the value of the corresponding field in the original data.

[0179] level: Node level, equal to the length of the dimension list (e.g., if the length of dims is 3, then level is 3).

[0180] rowIndex: The index of the current row in the original data array. This property is crucial; it establishes a direct and stable connection between the node and the original data row, forming the foundation for subsequent data access and editing synchronization.

[0181] 3.4 Generating Path Keys

[0182] The path key is a globally unique identifier for a node and is crucial for achieving the subsequent O(1) time complexity parent node lookup. The path key generation process is as follows: Figure 2 As shown, the specific execution steps are as follows:

[0183] 3.4.1 Determine the current dimension ID: Obtain the ID from the configuration of the target dimension (targetDim) as the current dimension ID (currentDimId), that is, currentDimId=targetDim.config.id.

[0184] 3.4.2 Generate parentPathKey: Generates based on the set of "all dimension IDs before the last dimension". The specific rule is: concatenate the IDs of all dimensions before the last dimension (i.e., config.id of dims[0] to dims[dims.length-2]) with underscores "_" in dimension order.

[0185] Boundary case: If the length of the dimension list is 1 (i.e. there is no dimension before the last dimension), then parentPathKey is an empty string ("").

[0186] Formula: parentPathKey=(dims.length>=2)?dims[0].config.id+"_"+…+dims[dims.length-2].config.id:"".

[0187] Example: For the dimension ID sequence ["1001", "1014", "prodX"], the parentPathKey of the "prodX" node is "1001_1014".

[0188] 3.4.3 Generate fullPathKey: Concatenate the parent pathkey with the current dimension ID to generate a full pathkey that serves as the unique identifier of the node.

[0189] Rule: If parentPathKey is not empty, then fullPathKey is the parent path key + "_" + the current dimension ID; if parentPathKey is empty, then fullPathKey is the current dimension ID.

[0190] Formula: fullPathKey=parentPathKey?${parentPathKey}_${currentDimId}:currentDimId.

[0191] Example:

[0192] If the parent path key is "1001_1014" and the current dimension ID is "prodX", then the fullPathKey is "1001_1014_prodX".

[0193] If the parent path key is empty and the current dimension ID is "1001", then fullPathKey will be "1001".

[0194] 3.4.4 Storing the path key: The generated fullPathKey is stored in the _fullPathKey property of the node object (i.e., node._fullPathKey=fullPathKey). This key is not only a globally unique identifier for the node, but the hierarchical path information it contains is also the core data foundation for subsequent instantaneous parent node lookup, establishment of parent-child relationships, and support for dynamic interactive positioning.

[0195] 3.5 Construct a complete node object and determine its type

[0196] Based on the above information, a node object is created. Then, by querying the expandable dimension set (drillableDimsSet) initialized in S2, it is determined whether the current node is an expandable node: isDrillable = drillableDimsSet.has(node.dimName).

[0197] Supplement differentiated attributes based on node type:

[0198] Regular nodes (isDrillable is false): Primarily used to form natural hierarchies. Their basic attributes include dimName, dimId, dimValue, level, rowIndex, and _fullPathKey, and an empty children array is initialized to store natural child nodes.

[0199] Expandable nodes (isDrillable is true): In addition to having all the basic properties of a regular node and an array of children, they also have associated properties that control their expanded / collapsed state, mainly including:

[0200] parentID: Taken from targetDim.config.parentID, used to establish parent-child relationships that can be expanded within the same dimension.

[0201] drillLevel: Drilling level, initial value is 0.

[0202] hasDrillChildren: Indicates whether there are expandable child nodes, initially set to false.

[0203] drillChildrenLoaded: Indicates whether expandable child nodes have been loaded; initially, it is false.

[0204] drillChildren: An expandable array of child nodes, initially empty.

[0205] 3.6 Node information is stored in the working container.

[0206] After a node is created, it is immediately stored in two core working containers initialized by S2 to support subsequent processes:

[0207] Store the path key map (nodesByPath): Use fullPathKey as the key and node object node as the value, and execute nodesByPath.set(fullPathKey, node). This operation is the basis for achieving O(1) time complexity parent node lookup, completely avoiding recursive traversal.

[0208] Store all node information in an array (allNodes): Push a tuple containing the building context into this array to provide a data source for the next stage of batch relationship building. The tuple typically contains: {node:node, parentPathKey:parentPathKey, fullPathKey:fullPathKey, isDrillable:isDrillable}.

[0209] Through step S3, this method systematically transforms each row of flat data into a precisely defined node. Each node not only carries the basic information required for display but also obtains precise "coordinates" in the tree space through a unique path key and establishes a direct "anchor" with the source data through the original data row index. The standardized set of nodes and efficient query mapping (nodesByPath) produced in this step lay the data foundation for the next stage of quickly assembling complex parent-child relationships.

[0210] S4: Establish node relationships and construct a dual-channel tree structure.

[0211] This step (S4) is the final assembly stage of the tree structure construction. Its core purpose is to quickly find the parent node by traversing all the nodes constructed in S3 twice, based on the differentiated rules of node type (normal node / expandable node), using path key mapping and caching mechanisms, establishing the hierarchical relationship between nodes, and finally forming a dual-channel tree structure containing "natural hierarchy" and "expandable hierarchy". This step is key to solving the problem that traditional solutions cannot support multi-dimensional independent expansion and collapse.

[0212] 4.1 Node Type Definition and Overview of Dual-Channel Structure

[0213] Before describing the relationship establishment process in detail, we must first clarify the two node types defined in this method and their roles in the dual-channel structure:

[0214] Regular nodes: These represent the hierarchical relationships that naturally form according to the order of the dimension fields in the original data, constituting the static trunk of the tree structure. The order in which dimension fields appear in the data rows (corresponding to the column order in the table) implicitly defines their hierarchy. For example, for data with the dimension order of dim1 (department), dim2 (employee), and dim3 (product), the regular node corresponding to the later dimension field is logically a child node of the regular node corresponding to the earlier dimension field. Their parent-child relationship is mounted and managed through the `children` array of the parent node.

[0215] Expandable nodes: These represent interactive relationships within the same dimension, established based on the parent node identifier (parentID), and can be dynamically expanded or collapsed. They are the core of enabling interactive data drill-down / drill-up. These nodes are associated with a set of attributes specifically for controlling their expanded / collapsed state (such as parentID, drillLevel, hasDrillChildren, drillChildren, etc.). Parent-child relationships are primarily established by finding the parent node within the same dimension based on parentID.

[0216] Through the differentiated design of the two node types mentioned above, this method aims to construct a dual-channel tree structure: a natural hierarchical channel maintained by children pointers, and an expandable hierarchical channel maintained by drillChildren pointers (and drillChildrenMap mapping).

[0217] 4.2 Step Overview and Initialization Preparation

[0218] This step uses the allNodes array output by S3 as the traversal source. This array stores a tuple of complete construction information for all nodes: {node, parentPathKey, fullPathKey, isDrillable}. Before traversal begins, the system ensures that the following core data structures are ready:

[0219] tree: An array of root nodes used to hold the top-level nodes.

[0220] nodesByPath: The mapping from path keys to node information is the foundation for achieving O(1) lookup.

[0221] drillChildrenMap: Expandable child node mapping, specifically used to temporarily store expandable child nodes in lazy loading mode.

[0222] drillableDimsSet: An expandable collection of dimensions used to assist in verifying node types.

[0223] At the same time, a temporary parent lookup cache (parentLookupCache) of type Map is initialized to store the completed lookup results, avoiding repeated queries on the nodesByPath mapping, thereby improving build performance.

[0224] 4.3 Efficient Parent Node Lookup Process Based on Caching Mechanism

[0225] The system sequentially traverses the allNodes array. For each item, it extracts its node object, parentPathKey, fullPathKey, and isDrillable identifier. The core of finding the parent node is the combination of O(1) lookup using nodesByPath mapping and cache optimization. For expandable nodes, a two-stage lookup logic is adopted, and the entire process follows the cache-first principle:

[0226] Step 1: Determine the lookup phase and generate cache keys

[0227] The current lookup stage is determined based on the node type and status, and a corresponding cache key (cacheKey) is generated:

[0228] A. Ordinary nodes: directly enter the "natural hierarchy lookup" stage, and the cache key directly uses its parentPathKey.

[0229] B. Expandable nodes:

[0230] (a) Priority lookup phase: First, attempt to find the "drill-down parent node" within the same dimension based on its explicitly configured parent node ID (parentID). The cache key generated for this phase is a combination of its parent path key and parent node ID (if parentPathKey is empty, only parentID is used), i.e., parentPathKey?${parentPathKey}:${node.parentID}:${node.parentID}.

[0231] (b) Last-Choice Lookup Phase: If the parent node is not found by parentID, it falls back to the "Natural Hierarchy Lookup" phase, that is, it looks up the parent node by its parentPathKey. The cache key in this phase is its parentPathKey.

[0232] Step 2: Cache Hit Check

[0233] Check if a record corresponding to the current cacheKey exists in parentLookupCache. If it exists (cache hit), directly retrieve the cached parent node information (parent node object or null), without accessing the nodesByPath mapping.

[0234] Step 3: Mapping lookup execution

[0235] If the cache is not hit, an actual lookup is performed in the nodesByPath mapping based on the lookup key determined in the current lookup phase:

[0236] "Natural Hierarchical Lookup": The lookup key is parentPathKey, and the function is parentNode = nodesByPath.get(parentPathKey).

[0237] "Explicit Related Lookup": The lookup key is a combination of parentPathKey and parentID (e.g., ${parentPathKey}_${node.parentID}), and the corresponding query is executed.

[0238] Step 4: Cache Update

[0239] The search results from step three (the found parent node object or null) are stored in parentLookupCache with the key cacheKey for reuse in subsequent identical queries.

[0240] This mechanism ensures that for multiple queries on the same lookup key, only the first query needs to be executed for the actual mapping query, and subsequent queries are cached accesses with O(1) time complexity, which greatly improves the construction efficiency.

[0241] 4.4 Differentiated processing logic for establishing node relationships

[0242] Based on the isDrillable identifier and the search results, the system executes completely different relationship establishment logic for the two types of nodes:

[0243] 4.4.1 Processing of ordinary nodes (establishing natural hierarchy)

[0244] Rule 1 (No parent path key): If the parentPathKey of a node is an empty string, it indicates that the node is the starting point of a certain dimensional path and should be treated as a top-level node, and directly added to the tree root array.

[0245] Rule 2 (Successful Search): If the parent node is successfully found through the caching mechanism, the current ordinary node is treated as a child node and attached to the child array of the parent node, thereby establishing a natural hierarchical relationship of the dimension.

[0246] Rule 3 (Search Failure): If the found parent node is null (i.e., the search fails), then perform a degradation process, adding the node as the root node to the tree array to ensure the integrity of the tree structure.

[0247] 4.4.2 Processing expandable nodes (establishing expandable hierarchy)

[0248] The prerequisite for processing expandable nodes is that isDrillable is true and the node's parentID attribute exists and is valid (not root identifiers such as "-2").

[0249] 4.4.2.1 Search and Location: The system first enters a priority search phase, attempting to locate the "drill-down parent node" within the same dimension by combining its parentPathKey and parentID to form a search key. If found, it is processed differently according to the configured loading mode; if not found, it enters a fallback search phase, searching for the parent node through its parentPathKey. If found in the fallback phase, it is added as a regular child node to the parent node's children array; if still not found, it is demoted, adding the node as the root node to the tree array.

[0250] 4.4.2.2 Differentiated Loading and Mounting (based on lazyLoadDrillChildren configuration):

[0251] Lazy loading mode (lazyLoadDrillChildren:true): When the parent node is found by parentID, the currently expandable node is not directly attached to the parent node, but is temporarily stored in drillChildrenMap. Using the parent node's _fullPathKey as the key, the current node is added to the corresponding child node array. At this time, the parent node's hasDrillChildren property is marked as true, and drillChildrenLoaded is false. Child nodes will be dynamically loaded when the user first triggers expansion.

[0252] Immediate loading mode (lazyLoadDrillChildren:false): When the parent node is found by parentID, the current expandable node is directly added to the parent node's drillChildren array. At the same time, the drill-down level of the current node is set to the parent node's drillLevel+1, and the parent node's hasDrillChildren and drillChildrenLoaded properties are both set to true.

[0253] 4.5 Final Formation of the Dual-Channel Tree Structure

[0254] After all nodes in the allNodes array have been processed:

[0255] Natural hierarchical tree: All ordinary nodes are connected to each other through children pointers, starting from the tree array to form a complete natural hierarchical tree that reflects the dimensional order.

[0256] Expandable hierarchical network: All expandable nodes, depending on the configuration, are either directly mounted to the parent node's drillChildren array (immediate loading mode) or temporarily categorized and stored in drillChildrenMap (lazy loading mode), forming an interactive relationship network independent of the natural hierarchy that supports dynamic expansion and collapse.

[0257] At this point, a logically complete dual-channel tree data model has been constructed. The contents of allNodes and nodesByPath, which were temporary data structures during the construction phase, have all been transferred and associated with the final tree model and will be cleaned up in subsequent steps.

[0258] Through step S4, this invention efficiently and accurately constructs a dual-channel tree structure. The children channel maintains a stable natural hierarchy, ensuring the structured presentation of basic data; the drillChildren channel (and drillChildrenMap) manages a flexible, expandable hierarchy, providing data support for multi-dimensional independent drill-down interaction. The combination of a caching mechanism and path-key-based O(1) lookup ensures that the overhead of establishing complex parent-child relationships remains extremely low even with massive amounts of data. The resulting tree structure is clear, with well-defined relationships and strong scalability, laying a solid data foundation for subsequent high-performance table rendering and a smooth interactive experience.

[0259] S5: Clean up temporary data and return the core result object

[0260] This step (S5) is the final and output stage of the tree structure construction process. After successfully constructing the complete dual-channel tree logic structure in step S4, this step aims to perform resource reclamation and result encapsulation: systematically clean up temporary data structures used only during the construction period to release memory, and encapsulate the final stable and usable core data model into a standardized result object for return, providing efficient and clear data input for subsequent table rendering and interactive control.

[0261] 5.1 Step Objectives and Input Context

[0262] The input for this step is the working context after complete processing from S1 to S4. At this point, the dual-channel tree structure has been logically established through pointers to children and drillChildren (or drillChildrenMap mapping) between nodes. This step has two core operational objectives:

[0263] Cleanup: Identifies and releases intermediate or temporary data containers that are no longer directly depended on after the tree structure is established, optimizing overall memory usage efficiency and improving the stability of the application when processing large-scale data.

[0264] Encapsulation and Return: The necessary parts of the subsequent processes (table row construction, rendering, and interaction) in the built result are organized into a well-structured and single-responsibility result object, which serves as the main output of this method and provides a standardized data interface for downstream modules.

[0265] 5.2 Identification and Cleanup of Temporary Data Structures

[0266] During the construction process, some data structures act as "scaffolding," their primary function ending once parent-child relationships are established. After ensuring all parent-child relationships are established, the system proactively cleans up this temporary data, reflecting the invention's refined performance considerations. The temporary data requiring cleanup mainly includes:

[0267] 5.2.1 All Node Information Array (allNodes):

[0268] Function: In stage S3, the construction information tuple of all nodes is stored, providing a linear traversal source for the batch establishment of parent-child relationships in stage S4.

[0269] Reason for cleanup: All node information has been linked to the final tree structure via pointers (children, drillChildren), and this array is no longer accessed.

[0270] Cleanup method: Clear the array or set its reference to null so that the garbage collection mechanism can reclaim the memory it occupies.

[0271] 5.2.2 Mapping of path keys to node information (nodesByPath):

[0272] Function: In stages S3 and S4, nodes are stored using fullPathKey as the key, which is the core data structure for achieving parent node lookup with O(1) time complexity.

[0273] Reason for cleanup: After the tree relationship is established, depth-first traversal through the root node array (tree) is the standard way to access nodes, and the reverse lookup function of this mapping is no longer needed in subsequent processes.

[0274] Cleanup method: Clear the mapping and release the reference.

[0275] 5.2.3 Parent Lookup Cache:

[0276] Purpose: A temporary cache (Map type) introduced in the S4 stage to optimize performance, used to store the results of completed parent node lookups, avoiding repeated queries on the nodesByPath mapping.

[0277] Reason for cleanup: Once the parent-child relationship between nodes is established, the data in this cache becomes invalid immediately.

[0278] Cleanup method: Clear cache mapping.

[0279] 5.3 Encapsulation and Definition of Core Result Objects

[0280] After the cleanup is complete, the system will encapsulate the persistent parts of the build results into a structured result object (which can be named treeCoreResult). This object, as the sole output of this method (createDrillableTree), is the sole data source for all subsequent processes. Its design follows the principle of "minimalism and sufficiency" to ensure a clear and efficient interface.

[0281] A complete core result object contains the following properties, as shown in Table 1:

[0282]

[0283] 5.4 Result Return and Process Endpoint

[0284] Finally, the main construction method completes its execution and returns the encapsulated core result object, marking the completion of the data construction phase of the multi-dimensional tree table control.

[0285] At this point, the caller obtains a clean, two-channel tree model containing complete logical relationships, an interactive data pool (drillChildrenMap) supporting on-demand loading, and necessary control parameters (maxDimension, drillableDims). This structured treeCoreResult object lays a solid and efficient data foundation for subsequent efficient and smooth table row data construction, visualization rendering, and dynamic user interaction. By actively cleaning up temporary data, this invention significantly optimizes memory usage efficiency while providing powerful functionality.

[0286] S6: Building and Rendering Table Row Data

[0287] This step (S6) is a crucial transformation link connecting the data model and the final visualization. Its core purpose is to transform the dual-channel tree structure into a flat, sequential two-dimensional table row data set based on the tree structure core result object returned by S5 through depth-first traversal, and finally complete the rendering and drawing of the table, achieving a precise mapping from the logical tree to the visual table.

[0288] 6.1 Core Inputs and Steps Objectives

[0289] The input for this step mainly includes:

[0290] 6.1.1 The core result object `treeCoreResult` returned by S5 has the following key components:

[0291] tree: The root node array serves as the starting point for traversal and contains a complete two-channel hierarchical relationship.

[0292] maxDimension: Maximum dimension level, used to control the number of dimension columns displayed in the table.

[0293] drillableDims: An array of expandable dimension names used to identify interactive nodes.

[0294] The raw data array originTableDatas obtained in S1 (6.1.2) is used to extract business indicator data.

[0295] The core objective of this step is:

[0296] Data transformation: By traversing the tree structure, the nested tree structure is transformed into a linear array of row data.

[0297] Data enrichment: Fill each row of data with complete dimension values, business metrics, and metadata that controls rendering.

[0298] View generation: Triggers the front-end rendering logic to convert the data into a user-visible table.

[0299] 6.2 Depth-first traversal generates flat row data

[0300] The system starts with the treeCoreResult.tree array, performs a depth-first traversal (DFS), and recursively visits the child nodes of each node to generate a flat table row data collection (tableRowDataList).

[0301] Traversal rules:

[0302] 6.2.1 When accessing a node, first generate the row data corresponding to that node.

[0303] 6.2.2 Subsequently, all child nodes (natural hierarchy) in its children array are processed recursively.

[0304] 6.2.3 Key Constraint: During the initial traversal, expandable child nodes that are in a collapsed state (i.e., the entire drillChildren array) are not accessed. These child nodes are only dynamically loaded and accessed when the user subsequently triggers an interaction to expand them, ensuring the efficiency of the initial rendering.

[0305] After the traversal is complete, tableRowDataList forms a flat array whose order strictly corresponds to the depth-first access order of the tree structure, providing the data foundation for subsequent table rendering.

[0306] 6.3 Single-row data construction process

[0307] For each node visited during traversal, the `buildRowDataForNode` function is responsible for constructing its corresponding table row data object. This process integrates the transformation from node information to all the attributes required for rendering:

[0308] 6.3.1 Determine the hierarchy and path:

[0309] The node's level can be obtained directly from its `level` attribute, or determined by parsing its full path key (`_fullPathKey`): Split `_fullPathKey` using underscores "_" as separators, and the length of the resulting array is the node's precise depth within the dimension. For example, `_fullPathKey="1001_1014_prodX"` splits into `["1001", "1014", "prodX"]`, with an array length of 3, indicating that the node is at the third level. The `pathContext` parameter can be used to maintain ancestor path information to aid in calculations.

[0310] 6.3.2 Extracting and Filling Dimension Values:

[0311] Each node stores only its own dimension (dimValue). To generate a complete table of data with a single row containing maxDimension columns:

[0312] For dimension columns that are less than or equal to the current node level, the actual dimension values ​​need to be filled in. This is typically done by querying the node's ancestor path information or tracing back the parent node chain. For example, for a third-level "Product X" node, the first and second dimension columns of its rows should be filled with "Department A" and "Employee 1" respectively. For dimension columns that are beyond the current node level, placeholders (such as "-") should be used.

[0313] 6.3.3 Correlation and Filling of Indicator Data:

[0314] The core operation utilizes the rowIndex (original data row index) stored in the node to directly index the original data array originTableDatas, instantly retrieving all business metrics for that row. This mechanism ensures a one-to-one correspondence between the table row data and the original business data rows, forming the foundation for subsequent data editing and synchronization.

[0315] 6.3.4 Generating Rendering and Interaction Control Meta-information:

[0316] In addition to dimension and metric values, the constructed row data object also needs to embed the following key metadata:

[0317] Merge Cell Identifier (dimMerge): An identifier is calculated for each dimension cell (usually based on its parentPathKey). During rendering, adjacent cells with the same dimMerge identifier can be merged (by setting rowspan) to achieve a visual grouping effect similar to a tree structure.

[0318] Node object reference: This refers to associating the node object itself within row data or within the cell data of a specific dimension column to which its current node belongs. This is the core bridge for quickly locating the corresponding tree node when implementing interactive functions such as click to expand or edit.

[0319] Indentation control information: The indentation amount is calculated based on the node's expandable level (drillLevel), so that the larger the drillLevel, the greater the visual indentation. This is used to distinguish drill-down nodes of different depths during front-end rendering.

[0320] Interaction state initialization: Mark whether the node corresponding to the row is an expandable node (isDrillable) and initialize interaction control properties, such as foldCount:0 (fold count), nextRow:null (next row reference), and isExpanded:false (expanded state), to prepare for efficient interaction in the S7 steps.

[0321] 6.4 Table Rendering

[0322] After traversal, tableRowDataList forms a flat, sequential collection of table rows. The front-end rendering component (based on native DOM, Canvas, or a modern front-end framework) uses this collection to render a multi-dimensional tree table with a hierarchical structure.

[0323] The rendering process mainly includes:

[0324] 6.4.1 Table Header Generation: Dynamically generate table column headers based on maxDimension and predefined business indicator fields.

[0325] 6.4.2 Row Traversal and Creation: Loop through tableRowDataList and create a corresponding table row (HTML element) for each row data object.

[0326] 6.4.3 Cell Filling and Style Settings:

[0327] Create dimension and indicator columns (HTML elements) for each row.

[0328] Fill the corresponding cells with the dimension text and indicator text from the row data.

[0329] Apply pre-calculated styles, such as using padding-left to achieve layer indentation.

[0330] Based on the dimMerge identifier, set the rowspan attribute for adjacent cells that need to be merged vertically.

[0331] 6.4.4 Binding of Interactive Controls:

[0332] Add expand / collapse icons (such as "+" / "-") to the dimension cell corresponding to the expandable node (isDrillable is true).

[0333] Bind the click event of the icon to the node object associated with the row data so that the corresponding tree node and its data can be quickly located during interaction.

[0334] 6.4.5 Mounting and Rendering: Mount the rendered entire table DOM tree to the specified container element on the page and finally present it to the user.

[0335] Through step S6, this invention efficiently transforms a complex dual-channel tree model into a visual table. This process deeply relies on and demonstrates the advantages of the initial design: using rowIndex to achieve direct association with the original data; using the path key system to accurately deduce the hierarchy and merging logic; and achieving efficient rendering of the initial state by distinguishing between children and drillChildren. The generated two-dimensional row data not only contains the displayed content but also embeds complete control metadata and node references, providing sufficient and structured data preparation for the next stage of achieving dynamic and high-performance expand / collapse interaction (S7), ultimately presenting a multi-dimensional tree table with clear hierarchy, accurate data, and interactive readiness.

[0336] S7: User-driven expand and collapse interaction

[0337] like Figure 3 As shown, this step (S7) is a crucial step in realizing the core interactive functions of the multi-dimensional tree table. Building upon the initial table rendering completed in S6, this step responds to user operations on expandable nodes. Based on an innovative collaborative mechanism of "inter-row reference association" and "collapse count control," it dynamically loads, inserts, hides, or displays the row data corresponding to its drill-down child nodes, and efficiently updates the table view. This mechanism replaces the recursive traversal of the entire tree structure with local linear operations, completely solving the performance bottleneck of interactive response latency in traditional solutions and achieving instantaneous response to expand / collapse operations in arbitrary depth and nested scenarios.

[0338] 7.1 Interaction Basics and State Initialization

[0339] The interactive functionality is built upon the flat row data set (tableRowDataList) generated in step S6 and the rendered table DOM structure. In the initial state, each row of data (corresponding to a tree node) is assigned the following interactive control attributes, forming the data foundation for all subsequent interactive logic, as shown in Table 2:

[0340]

[0341] All drillChildren child node rows of expandable nodes are not initially inserted into tableRowDataList and are in an unloaded or pending loading state.

[0342] 7.2 Initial Expand Operations: Loading Child Nodes and Inserting Rows

[0343] When a user clicks on a collapsed (+) expandable node row (denoted as row A) for the first time, the system executes the following process:

[0344] 7.2.1 Data Acquisition: Acquire the child node data of the corresponding node (targetNode) in row A according to the configured loading mode.

[0345] Lazy loading mode: Using targetNode._fullPathKey as the key, retrieve the temporary array of child nodes from treeCoreResult.drillChildrenMap returned by S5.

[0346] Immediate loading mode: Retrieves child nodes directly from the targetNode.drillChildren array.

[0347] 7.2.2 Sub-row Data Generation: Iterate through each obtained child node, call a row construction method similar to S6, and generate the corresponding table row data object. In the newly generated sub-row data, foldCount is initialized to 0, and an association is established with the parent row A.

[0348] 7.2.3 Row Data and DOM Insertion:

[0349] In the tableRowDataList array, find row A and the original next row that its nextRow reference points to (denoted as row B, i.e., A.originalNextRow).

[0350] Insert the generated sub-row data sequentially after row A and before row B.

[0351] In the table DOM, insert the newly generated child row element after the corresponding element in row A.

[0352] 7.2.4 Updating inline references:

[0353] Update row A reference: Update the nextRow of row A to point to the index of the first newly inserted child row.

[0354] Establish a sub-row reference chain: Establish a nextRow reference chain between the newly inserted sub-rows, so that the nextRow of the last sub-row points to the original row B.

[0355] 7.2.5 Status Update:

[0356] Set the isExpanded status of row A to true and update the expand icon to "-".

[0357] (In lazy loading mode) the child nodes are officially mounted into the targetNode.drillChildren array and drillChildrenLoaded is set to true.

[0358] 7.3 Collapse Operation: Hide Sub-rows by Collapse Count

[0359] When a user clicks on a node row (row A) that is already expanded (with a "-" icon), the collapse process is executed:

[0360] 7.3.1 Range Positioning: Starting from the next line after line A (A.nextRow), iterate through the nextRow reference chain until the originalNextRow of line A (i.e., the original line B) is encountered. This traversal range precisely includes all direct and indirect sub-lines under line A that need to be collapsed.

[0361] 7.3.2 Fold Count Update: For each row in the traversal range, increment its foldCount property by 1.

[0362] 7.3.3 View Update: Based on the rule "hide if foldCount>0", immediately set the DOM element corresponding to each row to be hidden (e.g., display:none).

[0363] 7.3.4 State Reset: Set the isExpanded state of row A to false and switch the icon back to "+".

[0364] 7.4 Expanding again: Displaying sub-rows by collapse count

[0365] When a user clicks on a node row (row A) that is collapsed but whose child nodes are loaded (isExpanded is false but drillChildrenLoaded is true), the process of expanding the node again is executed:

[0366] 7.4.1 Range positioning: Similar to the collapse operation, traverse to originalNextRow based on the nextRow reference chain.

[0367] 7.4.2 Fold Count Update: For each row in the traversal range, decrement its foldCount property by 1.

[0368] 7.4.2 View Update: Check the foldCount value for each row.

[0369] If foldCount equals 0 after subtracting, then the DOM element corresponding to that row is set to be displayed (e.g., display:'').

[0370] If foldCount is still greater than 0 (for example, if the row itself is a collapsed parent node), then it remains hidden.

[0371] 7.4.4 State Reset: Set the isExpanded status of row A to true and change the icon to "-".

[0372] 7.5 Control Mechanism for Nested and Independent Deployment

[0373] The "fold count" and "inline quote" mechanisms naturally support complex interaction scenarios:

[0374] Nested Expand / Collapse: Suppose row A has a child row C, and row C has a grandchild row D. When row A is collapsed, the foldCount of rows C and D are both incremented by 1 and hidden. When row A is expanded again, the foldCount of rows C and D are both decremented by 1. At this point, row C's foldCount returns to 0 and is displayed, but row D remains hidden because row C may still be collapsed (its foldCount comes from the operation on row C). This perfectly matches the user's intuitive expectation of collapsing nested levels.

[0375] Independent control at the same level: Multiple expandable child nodes under the same parent node can be expanded or collapsed independently without interfering with each other, because they each have their own independent foldCount state and nextRow reference chain.

[0376] 7.6 Summary of Technical Effects

[0377] Through the interaction mechanism implemented in step S7, this invention brings significant performance and user experience improvements:

[0378] Ultimate interactive performance: Expanding and collapsing operations only require a local linear traversal through the nextRow reference chain, with a time complexity of O(k) (where k is the number of rows directly affected). Only foldCount and the display status of a small number of DOM elements are updated, completely avoiding the overhead of recursively traversing the entire tree (O(N)) or large-scale DOM operations in traditional solutions.

[0379] Precise state management: The "fold count" model clearly encodes the explicit and implicit logic of rows with concise integer attributes. The logic is rigorous and perfectly supports nested expansion at any depth and independent control of sibling nodes.

[0380] Efficient rendering updates: View updates are data-driven, performing minimal DOM operations (show / hide) only on the affected rows, greatly reducing browser reflow and repaint.

[0381] Smooth user experience: The above technical optimizations ultimately translate into "instant response" in the user's perception. Even when faced with massive, in-depth, multi-dimensional data, there is no lag when expanding or collapsing the data.

[0382] Thus, by combining the complete process from S1 to S7, this invention achieves a closed-loop end-to-end process from flat data acquisition, dual-channel tree structure construction, efficient table rendering to high-performance interaction, providing a multi-dimensional tree table control generation method with complete functions, excellent performance, and a smooth user experience.

[0383] Figure 4 This is a schematic diagram of a multi-dimensional tree-shaped table control generation device. (Example) Figure 4 As shown, the multi-dimensional tree table control generation device includes: a data acquisition module 201, a structure initialization module 202, a node construction module 203, a relationship establishment module 204, a data cleaning and return module 205, a table rendering module 206, and an interactive control module 207.

[0384] The data acquisition module 201 is configured to acquire the raw data array, the expandable dimension name array, the maximum dimension level, and the configuration object sent by the backend. The raw data array is a flat data array, and each row of data contains multiple dimension fields and corresponding configuration information. The configuration object is used to control the construction and interaction behavior.

[0385] The structure initialization module 202 is configured to initialize the data structure, which includes: a root node array, an array of all node information, a path key to node information mapping, an expanded child node mapping, and an expanded dimension set;

[0386] The node building module 203 is configured to traverse data to build nodes, including: traversing each row of flattened data array, extracting all dimensions and creating a node for the last dimension of each row, saving the original data array row index of the row as the original data row index of the node, generating a parent path key, generating a complete path key based on the parent path key as the unique identifier of the node, and finally storing the created node information into a path key to node information mapping with the path key as the key and an array of all node information;

[0387] The relationship establishment module 204 is configured to quickly find the parent node and establish the parent-child relationship by traversing all nodes again and according to the two types of nodes constructed, based on their parent path keys in the mapping from path keys to node information. Finally, all nodes form a dual-channel tree structure containing natural hierarchy and expandable hierarchy according to their type and path. The two types of nodes are ordinary nodes and expandable nodes.

[0388] Data cleaning return module 205 is configured to clean up temporary data and return the core result object of the tree structure.

[0389] The table rendering module 206 is configured to traverse the recursive root node array based on the returned tree structure core result object, construct row data, and traverse the row data to render the table.

[0390] The interactive control module 207 is configured to support users in dynamically expanding or collapsing the rendered table.

[0391] Based on the above embodiments, the data acquisition module 201 can be specifically used to: obtain a flattened raw data array from the backend service interface; and parse and obtain an expandable array of dimension names, the maximum dimension level, and a configuration object containing configurations such as lazy loading mode.

[0392] Based on the above embodiments, the structure initialization module 202 can be used to: initialize the root node array, the array of all node information, the mapping from path keys to node information, expand the child node mapping and the expandable dimension set, so as to provide a basic data container for the subsequent construction of the tree structure.

[0393] Based on the above embodiments, the node construction module 203 can be specifically used to: traverse each row of the original data array, extract all valid dimension fields and their configuration information; create a node object for the last dimension of each row, save the original data row index, and set the basic attributes of the node; generate a parent path key and a complete path key based on the extracted dimension information, as unique identifiers for the node; and store the node information in the path key to node information mapping and the array of all node information.

[0394] Based on the above embodiments, the relationship establishment module 204 can be used to: quickly find the parent node of each node through a caching mechanism and path key mapping; according to the node type, mount ordinary nodes to the parent node's child node array, mount expandable nodes to the parent node's expandable child node array or temporarily store them in the expandable child node mapping according to lazy loading configuration; and execute degradation logic for nodes that fail to find their parent node and treat them as root nodes.

[0395] Based on the above embodiments, the data cleaning and return module 205 can be specifically used to: clean up the temporary data structures used during the construction process and release memory; encapsulate and return the core result object of the tree structure, which at least includes a root node array, an expanded child node mapping, a maximum dimension level, and an array of expandable dimension names. Based on the above embodiments, the table rendering module 206 can be specifically used to: based on the returned core result object of the tree structure, traverse the recursive root node array in a depth-first manner to construct a flat table row data set; and render and generate a multi-dimensional tree table with a hierarchical structure based on the table row data set. Based on the above embodiments, the interaction control module 207 can be specifically used to: respond to the user's operation to expand a table row, obtain child node data from the expanded child node mapping according to the complete path key of the node, generate and insert the corresponding table row data, and establish inter-row reference relationships; respond to the user's operation to collapse a table row, traverse the affected child row range according to the inter-row reference relationships, update the collapse count, and control the display or hiding state of the relevant rows, wherein the row is displayed when the collapse count is 0 and hidden when it is greater than 0.

[0396] In summary, the multi-dimensional tree table control generation device provided in this embodiment standardizes the input of raw data and configuration parameters required for multi-dimensional table construction through a data acquisition module, establishes a unified data storage carrier through a structure initialization module, completes the creation of basic nodes and generation of unique identifiers through a node construction module, quickly constructs a dual-channel tree structure with both natural and expandable hierarchies through re-traversal and path key mapping through a relationship establishment module, optimizes memory usage and outputs standardized core result objects through a data cleaning and return module, realizes the conversion of the tree structure into a visual table through a table rendering module, and supports the core interactive needs of users to dynamically expand and collapse the table based on inter-row referencing and collapse counting. Through the synergistic effect of the above modules, the problems of chaotic multi-dimensional display and low interactive efficiency of traditional tree table controls are solved, realizing the structured hierarchical display and efficient dynamic interaction of multi-dimensional data, making it easier for users to intuitively view the hierarchical relationship of multi-dimensional table data, and improving the user experience in enterprise-level data analysis scenarios.

[0397] It is worth noting that in the above embodiments of the multi-dimensional tree table control generation device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of this application.

[0398] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of different aspects of the invention exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.< / node> < / node>

Claims

1. A method for generating a multi-dimensional tree table control, characterized in that, include: Retrieve the raw data array, expandable dimension name array, maximum dimension level, and configuration object sent by the backend. The raw data array is a flat data array, with each row containing multiple dimension fields and corresponding configuration information. The configuration object is used to control the building and interaction behavior. Initialize the data structure, which includes: a root node array, an array of all node information, a path key to node information mapping, an expanded child node mapping, and an expanded dimension set; The process of traversing data to construct nodes includes: traversing each row of the flattened data array, extracting all dimensions and creating a node for the last dimension of each row, saving the original data array row index of the row as the original data row index of the node, generating a parent path key, generating a complete path key based on the parent path key as the unique identifier of the node, and finally storing the created node information into a path key to node information mapping with the path key as the key and an array of all node information. Specifically, generating a parent path key and then generating a complete path key based on the parent path key as a unique identifier for the node involves: From the extracted dimension fields, select the ID corresponding to the last dimension as the current dimension ID; The IDs of all dimensions preceding the last dimension are concatenated to generate the parent path key; The parent path key is concatenated with the current dimension ID to generate the complete path key; If there is no dimension preceding the last dimension, the parent path key is empty, and the complete path key is the current dimension ID. By traversing all nodes again, the parent node is quickly found and the parent-child relationship is established in the mapping from path key to node information according to the two types of nodes constructed. Finally, all nodes form a dual-channel tree structure containing natural hierarchy and expandable hierarchy according to their type and path. The two types of nodes are ordinary nodes and expandable nodes. Clean up temporary data and return the core result object of the tree structure; Based on the returned tree structure core result object, traverse the recursive root node array, construct row data, and traverse the row data to render the table. Users can dynamically expand or collapse the rendered table.

2. The method for generating a multi-dimensional tree table control according to claim 1, characterized in that, The configuration object includes at least one configuration parameter, which indicates whether lazy loading mode is enabled to control the loading behavior of expandable child nodes.

3. The method for generating a multi-dimensional tree table control according to claim 1, characterized in that, The traversal of data to construct nodes also includes: processing dimensionless data, specifically: when traversing the original data array, if the values ​​of all dimension fields in the currently traversed original data row are empty, then a root node with a dimension name of a predefined root identifier is created, and the created root node is directly added to the root node array.

4. The method for generating a multi-dimensional tree table control according to claim 1, characterized in that, The types of nodes constructed are divided into: ordinary nodes and expandable nodes, among which, The ordinary node is used to represent the natural hierarchical relationship formed according to the order of the dimension fields of the original data, wherein the ordinary node corresponding to the next dimension field is a child node of the ordinary node corresponding to the previous dimension field. The expandable node is used to represent a cross-level relationship that can be dynamically expanded or collapsed based on the parent node identifier; The expandable node is associated with an attribute used to control its expanded or collapsed state.

5. The method for generating a multi-dimensional tree table control according to claim 1, characterized in that, The process involves iterating through all nodes again, and based on the two types of nodes constructed, quickly finding the parent node and establishing the parent-child relationship in the mapping from path key to node information according to its parent path key. This includes finding the parent node through a caching mechanism. Specifically: When looking up the parent node of the current node, if the node type is a normal node, the corresponding cache key is generated based on its parent path key; if the node type is an expandable node, the corresponding cache key is generated based on its parent path key and parent node ID, or the corresponding cache key is generated based on its parent path key. Query the parent node to find the cache based on the cache key generated for the current node; If the cache is hit, the parent node information of the cache is obtained directly; If the cache is not hit, a lookup is performed in the mapping from the path key to the node information, and the lookup result is stored in the parent node lookup cache.

6. The method for generating a multi-dimensional tree table control according to claim 5, characterized in that, The process of quickly finding the parent node and establishing the parent-child relationship based on the mapping from path key to node information according to the two types of nodes constructed is as follows: For expandable nodes, if the current expandable node has a valid parent node ID, the parent node is first located by combining the parent path key of the current expandable node with the parent node ID to form a lookup key. If the parent node is found by the lookup key, differentiated processing is performed according to the configured loading mode. If the parent node is not found by the lookup key, the parent node is searched by the parent path key of the current expandable node. If the parent node is found, the current expandable node is attached to the parent node's child node array. If the parent node is not found, the current expandable node is demoted to the root node and added to the root node array. For a regular node, if the current regular node has no parent path key, then the current regular node is added to the root node array as the root node; if the current regular node has a parent path key, then the corresponding parent node is searched. If the search is successful, the current regular node is mounted to the parent node's child node array; if the search fails, then the current regular node is added to the root node array as the root node.

7. The method for generating a multi-dimensional tree table control according to claim 6, characterized in that, If the parent node is found using the search key, then differentiated processing is performed according to the configured loading mode, specifically: If lazy loading mode is enabled, the node is temporarily stored in the expanded child node mapping; If lazy loading is not enabled, it is directly attached to the expanded child node array of the parent node, and the drill-down level of the node is set to the drill-down level of the parent node plus one.

8. The method for generating a multi-dimensional tree table control according to claim 1, characterized in that, The process involves traversing the recursive root node array based on the returned tree structure core result object, constructing row data, and then traversing this row data to render the table. Specifically: Traverse the root node array and recursively visit the child nodes of each node in a depth-first manner to generate a flat table row data set; wherein, during the traversal, expandable child nodes that are in a collapsed state are not visited. When traversing each node, the node level is determined based on its full path key, and the corresponding data is extracted from the original data array according to its original data row index to construct a table row and add it to the table row data set; Based on the set of table row data, a multi-dimensional tree table with a hierarchical structure is rendered and generated.

9. The method for generating a multi-dimensional tree table control according to claim 8, characterized in that, The user can dynamically expand or collapse the rendered table, specifically: In response to the user's first expansion operation on the expandable node, the corresponding expanded child node data is obtained from the expanded child node mapping according to the complete path key of the node, the row data to be inserted is generated, and it is inserted into the table row data set after the corresponding row of the node; After insertion, establish inter-line references, point the next line reference of the expanded line to its original next line, and set the expanded state flag of the expanded line to a value that indicates the expanded state; In response to the user's collapse operation on the expanded node, starting from the expanded row, traverse to the target row according to the next row reference of the expanded row, increment the collapse count of each traversed row by one, and set the expanded state flag of the expanded row to the value indicating the collapsed state. In response to the user's operation of expanding a collapsed node again, starting from the expanded row, traverse to the target row according to the next row reference of the expanded row, decrement the collapse count of each row traversed, and set the expanded state flag of the expanded row to a value indicating the expanded state. The display or hiding of a row is determined by its fold count.

10. A method for generating a multi-dimensional tree table control according to claim 9, characterized in that, The fold count is used to control the display or hiding state of rows: A row is displayed in the table when its collapse count is 0; it is hidden in the table when its collapse count is greater than 0.

11. A device for generating a multi-dimensional tree-shaped table control, characterized in that, include: The data acquisition module is configured to acquire the raw data array, expandable dimension name array, maximum dimension level, and configuration object sent by the backend. The raw data array is a flat data array, with each row containing multiple dimension fields and corresponding configuration information. The configuration object is used to control the building and interaction behavior. The structure initialization module is configured to initialize the data structure, which includes: a root node array, an array of all node information, a path key to node information mapping, an expanded child node mapping, and an expandable dimension set; The node building module is configured to traverse data to build nodes, including: traversing each row of the flattened data array, extracting all dimensions and creating a node for the last dimension of each row, saving the original data array row index of the row as the original data row index of the node, generating a parent path key, generating a complete path key based on the parent path key as the unique identifier of the node, and finally storing the created node information into a path key to node information mapping with the path key as the key and an array of all node information. Specifically, generating a parent path key and then generating a complete path key based on the parent path key as a unique identifier for the node involves: From the extracted dimension fields, select the ID corresponding to the last dimension as the current dimension ID; The IDs of all dimensions preceding the last dimension are concatenated to generate the parent path key; The parent path key is concatenated with the current dimension ID to generate the complete path key; If there is no dimension preceding the last dimension, the parent path key is empty, and the complete path key is the current dimension ID. The relationship establishment module is configured to quickly find the parent node and establish the parent-child relationship by traversing all nodes again and according to the two types of nodes constructed, based on their parent path keys in the mapping from path keys to node information. Finally, all nodes form a dual-channel tree structure containing natural hierarchy and expandable hierarchy according to their type and path. The two types of nodes are ordinary nodes and expandable nodes. The data cleaning and return module is configured to clean up temporary data and return the core result object of the tree structure. The table rendering module is configured to traverse the recursive root node array based on the returned tree structure core result object, construct row data, and then traverse the row data to render the table. The interactive control module is configured to support users in dynamically expanding or collapsing the rendered table.

Images