Multi-dimensional tree form control generation method and device
By constructing a dual-channel tree structure and a lazy loading mechanism, the limitations of multi-dimensional expansion and interaction delays in existing tree table controls are solved, realizing an efficient and flexible multi-dimensional data analysis tool suitable for enterprise-level data analysis applications.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-02-26
- Publication Date
- 2026-03-27
AI Technical Summary
Existing tree table controls suffer from limitations in multi-dimensional data display, such as single-dimensional expansion, low data processing efficiency, delayed interactive response, and poor scalability, making it impossible to achieve independent drill-down and efficient interaction across multiple dimensions.
It adopts a dual-channel tree structure based on flattened raw data, which combines 'natural hierarchy' and 'expandable hierarchy'. It combines path key unique identifier, parent node lookup cache and inter-row reference folding counting mechanism to support the synchronous expansion and collapse of multi-dimensional fields, and introduces lazy loading mode to optimize performance.
It enables multi-dimensional independent interactive development, improves data analysis efficiency, optimizes data processing and transmission performance, reduces interaction latency, enhances the flexibility and stability of the system architecture, and meets the high standards required for enterprise-level data analysis applications.
Smart Images

Figure CN121743333A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of data processing, in particular to a multi-dimensional tree table control generation method and device. BACKGROUND
[0002] In the field of big data analysis and business intelligence (BI), the front-end tree table control is a core component for displaying multi-dimensional data with hierarchical relationships, and is widely used in organizational structure management, product classification analysis, project task tracking, etc. Such data usually has two key characteristics: one is multi-dimensionality (such as involving multiple analysis perspectives such as departments, employees, products, etc.), and the other is the natural hierarchical relationship within each dimension. An ideal control should support users to independently expand, drill down and collapse operations on different dimension paths in the same view to achieve efficient cross-analysis.
[0003] However, the tree table scheme in the prior art has significant limitations in achieving the above goals, mainly in the aspects of data construction, interaction performance and scalability: First, there are defects in the data model and construction logic. Most schemes only support expansion operations along a single preset dimension path, and cannot achieve independent and synchronous expansion and collapse of multiple dimension fields. This forces users to perform multiple page jumps or view switches when analyzing, disrupting the continuity of the analysis process. In addition, to implement a tree structure, a common scheme is to return deeply nested data from the backend, resulting in transmission redundancy and heavy front-end parsing burden; another common scheme is to recursively construct based on flat data in the front-end, but lacks efficient node positioning and association mechanisms (such as relying only on recursive traversal to establish parent-child relationships), resulting in slow construction speed and inability to support fast parent node queries.
[0004] Secondly, there are bottlenecks in interaction performance and user experience. Due to the constraints of the underlying data model and rendering mechanism, the expansion / collapse interaction of existing controls is slow. A common reason is that each interaction operation (such as collapsing a node) may need to re-traverse or calculate the entire (or local) tree structure to determine which child nodes need to be hidden or displayed. When the tree structure is large or the nesting level is deep, this traversal overhead will cause significant operation delays. At the same time, large-scale dynamic insertion and deletion of DOM elements can easily cause the browser to frequently reflow and repaint, further exacerbating performance loss.
[0005] Furthermore, the design is insufficient in data association and architecture extensibility. The association between the tree nodes of many solutions and the original business data is indirect or loose, which leads to complexity and errors in synchronously updating the underlying data source after editing the data in the table. In addition, the existing solutions are deeply coupled with specific UI frameworks or third-party plugins, and their display forms and interactive behaviors are fixed, making it difficult to flexibly adapt to enterprise-level personalized needs such as customizing hierarchical indentation and dynamically rendering columns. In terms of loading strategy, there is often a dilemma: full loading leads to initial rendering lag when the data volume is large, while using pagination loading destroys the continuity of the tree structure and affects user experience.
[0006] In summary, the existing technology fails to provide a tree table control generation method that efficiently constructs from flat data, supports multi-dimensional independent drilling, and has high-performance expansion and collapse interaction capabilities. Therefore, there is an urgent need for an innovative technical solution to systematically solve the core problems of data construction efficiency, interaction real-time performance, and architecture flexibility. SUMMARY
[0007] The present application aims to provide a multi-dimensional tree table control generation method and device, which aims to overcome the problems of existing tree tables that only support single-dimensional expansion, low data processing efficiency, delayed interaction response, and poor extensibility. Based on flat original data, the present application constructs a dual-channel tree structure that coexists with "natural levels" and "expandable levels", supports independent and synchronous expansion and collapse of multi-dimensional fields, and integrates path key unique identification, parent node lookup cache, and inter-row reference folding count mechanism to realize fast construction of node relationships and high-performance dynamic interaction, ultimately providing users with an efficient, flexible, and responsive multi-dimensional data analysis tool.
[0008] In the first aspect, the present application provides a multi-dimensional tree table control generation method, and the technical solution adopted to solve the above technical problems is as follows: Obtain the original data array, the expandable dimension name array, the maximum dimension level, and the configuration object issued by the background, wherein the original data array is a flat data array, each row of data contains multiple dimension fields and corresponding configuration information, and the configuration object is used to control the construction and interaction behavior; Initialize the data structure, wherein the data structure includes: a root node array, an all-node information array, a path key to node information mapping, an expanded child node mapping, and an expandable dimension set; Traverse the data construction node, 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, and generating a parent path key, then generating a complete path key as a unique node identifier based on the parent path key, and finally storing the created node information in the path key to node information mapping with the path key as the key and the all node information array; By traversing all nodes again, according to the two types of nodes constructed, the parent nodes are quickly found in the path key to node information mapping according to their parent path keys and the parent-child relationship is established, and finally all nodes form a double-channel tree structure containing natural levels and expandable levels according to their types and paths, wherein the two types of nodes are divided into ordinary nodes and expandable nodes; Clean up temporary data and return a tree structure core result object; Based on the returned tree structure core result object, traverse the recursive root node array, construct row data, and traverse the row data for table rendering; The user can perform dynamic expansion or folding interaction on the rendered table.
[0009] Optionally, the configuration object includes at least one configuration parameter, which is used to indicate whether to enable the lazy loading mode to control the loading behavior of expandable child nodes.
[0010] Optionally, the traversing 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, 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.
[0011] Optionally, the generation of the parent path key and the generation of the complete path key as the unique node identifier based on the parent path key are as follows: Select the ID corresponding to the last dimension from the extracted dimension fields as the current dimension ID; Splice the IDs of all dimensions before the last dimension to generate a parent path key; Splice the parent path key and the current dimension ID to generate the complete path key; If there is no dimension before the last dimension, the parent path key is empty, and the complete path key is the current dimension ID.
[0012] Optionally, the types of nodes constructed are: ordinary nodes and expandable nodes; wherein, The common node is used for representing a natural hierarchical relationship formed in the order of the dimension fields of the original data, wherein a common node corresponding to a subsequent dimension field is a child node of a common node corresponding to a previous dimension field. The expandable node is used for representing a cross-hierarchical relationship which can be dynamically expanded or folded based on the parent node identifier. The expandable node is associated with an attribute used for controlling the expansion or folding state thereof.
[0013] Optionally, the two types of nodes are built, and the parent nodes are quickly found in the mapping of the path keys to the node information and the parent-child relationship is established according to the parent path keys of the two types of nodes, including finding the parent nodes through a cache mechanism, specifically as follows. When finding the parent node of the current node, if the node type is a common node, a corresponding cache key is generated according to the parent path key thereof; if the node type is an expandable node, a corresponding cache key is generated according to the parent path key and the parent node ID thereof, or a corresponding cache key is generated according to the parent path key thereof. The parent node is found according to the cache key generated for the current node; if the cache hits, the cached parent node information is directly obtained; if the cache misses, the finding is performed from the mapping of the path keys to the node information, and the finding result is stored in the parent node finding cache.
[0014] Further optionally, the two types of nodes are built, and the parent nodes are quickly found in the mapping of the path keys to the node information and the parent-child relationship is established according to the parent path keys of the two types of nodes, specifically as follows. For the expandable node, if the current expandable node has a valid parent node ID, the parent node is located through a finding key formed by combining the parent path key and the parent node ID of the current expandable node, if the parent node is found through the finding key, the differential processing is performed according to the configured loading mode; if the parent node is not found through the finding key, the parent node is found through the parent path key of the current expandable node: if the parent node is found, the current expandable node is mounted to the child node array of the parent node; if the parent node is not found, the current expandable node is downgraded to a root node and added to the root node array. For the common node, if the current common node has no parent path key, the current common node is added to the root node array as a root node; if the current common node has a parent path key, the corresponding parent node is found, if the finding is successful, the current common node is mounted to the child node array of the parent node; if the finding fails, the current common node is added to the root node array as a root node.
[0015] Further optionally, if the parent node is found through the finding key, the differential processing is performed according to the configured loading mode, specifically as follows. If the lazy loading mode is enabled, the node is temporarily stored in the expanded child node mapping of the parent node; If the lazy loading mode is not enabled, the node is directly mounted to the expanded child node array of the parent node, and the drilling level of the node is set to the drilling level of the parent node plus one.
[0016] Optionally, based on the returned tree structure core result object, the root node array is traversed recursively to construct row data, and the row data is traversed for table rendering, specifically: The root node array is traversed to recursively access the child nodes of each node in the array in a depth-first manner to generate a flat table row data set; wherein, in the traversal process, the expandable child nodes in the collapsed state are not accessed temporarily; When each node is traversed, the node level is determined according to its complete 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; According to the table row data set, a multi-dimensional tree table with hierarchical structure is rendered.
[0017] Further optionally, the user can perform dynamic expansion or collapse interaction on the rendered table, specifically: In response to the first expansion operation of the user 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 after the corresponding row of the node in the table row data set; After insertion, an inter-row reference relationship is established, the next row of the expanded row is referenced to its original next row, and the expansion state identifier of the expanded row is set to a value representing the expanded state; In response to the collapse operation of the user on the expanded node, starting from the expanded row, the target row is traversed according to the next row reference, the folding count of each row traversed is increased by one, and the expansion state identifier of the expanded row is set to a value representing the collapsed state; In response to the re-expansion operation of the user on the collapsed node, starting from the expanded row, the target row is traversed according to the next row reference, the folding count of each row traversed is decreased by one, and the expansion state identifier of the expanded row is set to a value representing the expanded state; Wherein, the display or hiding of a row is determined by the value of its folding count.
[0018] Further optionally, the folding count is used to control the display or hiding state of the row: When the folding count of a row is 0, the row is displayed in the table; when the folding count is greater than 0, the row is hidden in the table.
[0019] 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: A multi-dimensional tree table control generation device, comprising: 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. 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.
[0020] Compared with the prior art, the multi-dimensional tree table control generation method and apparatus of the present invention have the following advantages: 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.
[0021] 2. Data processing efficiency and transmission performance optimization. The method of constructing a tree structure based on flattened raw data is adopted, which reduces the transmission redundancy caused by nested data structure from the source, especially suitable for large data scenarios. The innovative use of complete path key to uniquely identify nodes, combined with parent node lookup cache mechanism, realizes the rapid establishment of node relationship and O(1) time complexity lookup of parent node, replacing the inefficient recursive traversal in traditional scheme, greatly improving the construction speed and overall performance of tree structure.
[0022] 3. Real-time and efficient interaction response, significantly reducing rendering performance loss. The expansion and folding control mechanism of "inter-row reference association and folding count" is introduced, so that no matter how deep the tree structure is nested, the expansion or folding operation only needs to adjust the local row count and switch the state, without the need to re-traverse or calculate the entire tree structure, greatly reducing the interaction delay. This mechanism combined with on-demand lazy loading mode (expandable child nodes are only loaded when first expanded), effectively avoids frequent DOM rearrangement and repainting, while maintaining the integrity of the tree structure, ensuring smooth and immediate user interaction experience.
[0023] 4. Data association is close and direct, and the system architecture is flexible and highly expandable. Each tree node retains an index pointing to the original data row, so that the editing operation in the front-end table can be directly mapped and synchronized to update the underlying business data source, simplifying the data maintenance process and reducing the risk of data inconsistency. In addition, the core of the scheme does not depend on specific UI frameworks or third-party plugins, realizing the decoupling of data model and display layer, easily supporting custom hierarchical indentation, dynamic column rendering and other diversified enterprise-level customization requirements, with good architectural flexibility and scalability.
[0024] 5. Perfect exception handling mechanism, stable and reliable operation. For abnormal scenarios such as no-dimension data row and parent node lookup failure that may occur during data construction, the invention designs bottom-up processing rules such as creating root nodes and downgrading nodes to root nodes, ensuring the normal construction of tree structure under various data conditions.
[0025] 6. Balancing functionality 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 drilling, the invention ensures high-performance operation of the system under large data volume through multiple technical means such as path key, cache optimization, and lazy loading. The final solution achieves an excellent balance between functionality, real-time interaction, and system resource consumption, fully meeting the high-standard requirements of modern business intelligence (BI) and other enterprise-level data analysis applications. BRIEF DESCRIPTION OF DRAWINGS
[0026] APPENDIX Figure 1This is a flowchart illustrating the overall process of generating a multi-dimensional tree-shaped table control. Appendix Figure 2 This is a flowchart illustrating the path key generation process for a multi-dimensional tree-shaped table control generation method. Appendix Figure 3 It is a flowchart for dynamically expanding or collapsing an already rendered table. Appendix Figure 4 This is a schematic diagram of the structure of a multi-dimensional tree table control generation device. Detailed Implementation
[0027] 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.
[0028] Example 1: As Figure 1 As shown, this embodiment proposes a method for generating a multi-dimensional tree table control, including: S1: Obtain build parameters and raw data 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: 1.1 Obtaining the original data array 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: const originTableDatas=[ {dim1:"Marketing Department", dim1_config:{id:"1001",name:"Organizational Structure",parentID:"-2"}, dim2:"Employee A", dim2_config:{id:"1014",name:"Employee",parentID:"1001"}, dim3:"Product X", dim3_config:{id:"64eef93a9271e20001a1da9e",name:"Product Category"}, agg_year_revenue:150000, agg_year_revenue_fmt: "150,000"}, { dim1: "East China Region", dim1_config: {id: "RegionEast", name: "East China Region", parentID: "-2"}, dim2: "Shanghai City", dim2_config: {id: "CitySh", name: "Shanghai City", parentID: "RegionEast"}, dim3: "Product A", dim3_config: {id: "ProdA", name: "Product A"}, revenue: 150000, revenue_fmt: "150,000"}, / / ... More data rows]; Data description: Dimension fields (such as dim1, dim2, dim3): Represent different analysis perspectives of the data, and their order usually implies the default natural hierarchical relationship (for example, dim1 can be the parent of dim2).
[0029] Dimension configuration object (such as dim1_config): Contains the core metadata of the dimension. The id is the unique identifier; the parentID is used to establish the parent-child association for expandable dimensions (drilling down), where special values (such as "-2") indicate that the node has no parent node and is the root node; the name is the dimension name.
[0030] Metric fields (such as agg_year_revenue, revenue): Specific business numerical data that needs to be displayed and analyzed.
[0031] 1.2 Obtain an array of drillable dimension names 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.
[0032] const drillableDims = ["dim1", "dim2"]; The above configuration indicates that the nodes corresponding to dim1 (such as "organization structure" / "East China region") and dim2 (such as "employee" / "province and city") are defined as "expandable nodes", which can be clicked to drill down. The dimensions not in the array (such as dim3 in this example) are considered as "normal nodes", only participate in forming a static hierarchy, and do not have independent expansion interaction function.
[0033] 1.3 Get the maximum dimension level The system obtains an integer value maxDimension, which is used to limit the maximum dimension depth that needs to be constructed and processed for this table display, to prevent display confusion due to too many dimensions, and to provide display flexibility.
[0034] const maxDimension = 3; This configuration means that even if the original data may contain more dimension fields, only the first three dimensions (dim1, dim2, dim3) are processed to build the tree structure.
[0035] 1.4 Get configuration object The system obtains a configuration object (options) to control the construction strategy and interaction behavior of the tree structure. The object contains at least one core parameter lazyLoadDrillChildren, which is used to enable or disable the lazy loading mode to control the loading behavior of expandable child nodes. The configuration object is the key to realize performance optimization and flexible switching of interaction mode.
[0036] const options = { lazyLoadDrillChildren: true / / enable lazy loading mode rootNodeName: "Total" / / optional, used for the display name of the root node created when there is no dimension data}; Lazy loading mode details: Enable lazy loading mode (lazyLoadDrillChildren: true): In this mode, the child node data of all expandable nodes will not be directly mounted to the tree structure at initialization, but will be temporarily stored in a separate mapping table (drillChildrenMap). Only when the user first clicks to expand the node, its child nodes are dynamically loaded and rendered. This mode greatly optimizes the initialization performance and memory usage, especially suitable for scenarios with large amounts of child node data.
[0037] Disable lazy load mode (immediate load) (lazyLoadDrillChildren: false): All expandable children will be mounted directly to the parent's drillChildren array (i.e. the array of expanded children) in the tree construction phase, achieving full initialization loading, so that there is no data loading delay for the first expansion operation.
[0038] Through this step, the system has completed all input preparations before construction. The flattened original data array ensures the efficiency of transmission and parsing; the expandable dimension array and the maximum dimension level together define the morphology and interaction boundary 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 process.
[0039] S2: Initialize core data structures This step is executed after obtaining all input parameters (S1), and the core purpose is to create and initialize various basic data containers required for building multi-dimensional tree tables. These containers build an efficient and clear temporary "workbench" in memory, providing structured support for subsequent node creation, quick establishment of parent-child relationships, lazy loading storage, and interaction control. The following five types of core data structures are initialized: 2.1 Root node array (tree): Function: As the root container and the only entry of the final constructed multi-dimensional tree structure. All nodes at the top level of the tree (including nodes without a parent path, degraded nodes that fail to find a parent node, and special root nodes created for dimensionless data) will be collected in this array. It is the starting point for subsequent traversal to generate table row data and perform table rendering.
[0040] Initialization method: Create an empty array.
[0041] Code example: const tree=[]; Final form: Array <node>Where Node is a node object.
[0042] 2.2 allNodes array: Purpose: Serve as a temporary centralized workspace during the tree construction phase. It is used to store the complete information tuples of all created nodes, typically including the node object itself, its parent path key (parentPathKey), full path key (fullPathKey), and identification of whether it is drillable (isDrillable). The main purpose of this array is to provide a unified, linear traversal source for the subsequent "establish parent-child relationship" phase, avoiding repeated traversal of the original data array.
[0043] Initialization method: Create an empty array.
[0044] Code example: const allNodes = []; / / Format: [{ node, parentPathKey, fullPathKey, isDrillable}, …] Life cycle: This structure is temporary storage, and after the parent-child relationship between nodes is established, the memory it occupies will be released, reflecting the optimized management of memory resources.
[0045] 2.3 nodesByPath mapping: Purpose: It is the core fast lookup dictionary of this scheme to achieve high performance. This mapping takes the unique identifier of each node, the full path key (fullPathKey), as the key (Key), and the corresponding node object as the value (Value) to construct. Its core value lies in achieving O(1) time complexity lookup of parent nodes. When determining 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 abandoning the time-consuming recursive or loop traversal lookup in traditional schemes, greatly improving the construction speed of tree structure.
[0046] Initialization method: Create an empty Map object.
[0047] Code example: const nodesByPath = new Map(); / / Key: fullPathKey (String), Value: Node object 2.4 drillChildrenMap mapping: Purpose: A temporary storage for children nodes designed for lazy loading mode. When the lazyLoadDrillChildren parameter in the configuration object is set to true, all children nodes identified as expandable (isDrillable is true) will not be mounted directly under their parent node during initialization. Instead, the system will store all the expandable children nodes belonging to a parent node in a map with the parent's full path key as the key and the array of children nodes as the value. When the user triggers the first expansion of a node on the frontend interface, the system will retrieve the corresponding array of children nodes from the map based on the node's path key and perform dynamic loading and rendering. This mechanism delays the loading of potential child nodes and DOM rendering overhead until it is actually needed, significantly optimizing the initial loading performance and memory usage of the table.
[0048] Initialization method: Create an empty Map object.
[0049] Code example: const drillChildrenMap = new Map(); / / Key: parent node fullPathKey (String), value: child node array (Array <node>) 2.5 drillableDimsSet: Purpose: A helper set for efficient node type judgment. It is converted from the input parameter drillableDims array. During the process of creating node objects from data rows, it is frequently needed to judge whether the current processing dimension supports drill-down interaction. Using this set for judgment (drillableDimsSet.has(dimName)) has a time complexity of O(1), which is significantly more efficient than sequential search in the original array (O(n)).
[0050] Initialization: Convert the drillableDims array to a Set collection.
[0051] Code example: const drillableDims = ["dim1", "dim2"]; / / input from S1 step const drillableDimsSet = new Set(drillableDims); Example code snippet and collaborative relationship: The following shows the typical implementation framework of S1 and S2 steps in the core method createDrillableTree, and explains the collaborative logic between data structures: function createDrillableTree(data, drillableDims, maxDimension, options = {}) { / / S1 & S2: receive parameters and initialize core data structures const { lazyLoadDrillChildren = true} = options; / / read lazy loading configuration (S1.4) const tree = []; / / 1. root node array: "display rack" of the final product const allNodes = []; / / 2. all node information array: "assembly line list" during construction const nodesByPath = new Map(); / / 3. path key-node mapping: "part index table" for O(1) search const drillChildrenMap = new Map(); / / 4. drill-down child node mapping: "temporary storage area for unassembled parts" for lazy loading const drillableDimsSet = new Set(drillableDims); / / 5. Expandable dimensions set: "assembly instruction table" for quick decision / / … Subsequent steps (S3 / S4): Based on the above structure, traverse the data, build nodes and establish relationships Data structure collaborative workflow and advantages: Construction phase: When traversing the original data, the created node information is stored in allNodes, and the mapping relationship between its fullPathKey and the node object is recorded in nodesByPath, paving the way for subsequent quick lookup. According to drillableDimsSet, determine the node type, if it is an expandable node and enable lazy loading, then store it in drillChildrenMap according to the parent path key.
[0052] Relationship establishment phase: Traverse allNodes, use nodesByPath to achieve instant lookup of parent nodes. Through the node type distinguished by drillableDimsSet, decide whether it is hung in the children array as a normal child node, or processed according to the lazyLoadDrillChildren configuration as an expandable child node (immediately mounted to drillChildren or temporarily stored in drillChildrenMap).
[0053] Interaction phase: When the user triggers the expansion operation, if it is in lazy loading mode, then implement on-demand loading of child nodes through drillChildrenMap. The final tree array serves as the root of the complete tree structure, driving the rendering and display of the table.
[0054] Through this step of systematic data structure initialization and parameter configuration, a data processing framework with clear responsibilities and efficient collaboration is built. This design solves the problems of low construction efficiency, high memory occupation and poor scalability caused by data structure confusion in existing technologies, laying a solid technical foundation for smoothly and flexibly converting flat data into complex multi-dimensional interactive tree tables. Through the control of the lazyLoadDrillChildren parameter, a flexible balance between performance and user experience is achieved.
[0055] S3: Traverse the original data and build nodes This step (S3) is one of the core links of tree structure construction, its purpose is to traverse the original flat 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 data basis for subsequent parent-child relationship establishment. The specific implementation process is as follows: 3.1 Traversing original data and dimension extraction The system starts to traverse each row in the original data array (originTableDatas) in sequence. For the current row (indexed as rowIndex), according to the maximum dimension level (maxDimension), extract all valid dimension fields and their configuration objects of the row to form a dimension list (dims). According to the agreement with the background interface, each dimension field must have a valid value and a non-empty configuration object. The system checks each dimension in turn (e.g. dim1, dim1_config; dim2, dim2_config…), and only when both the dimension value and the configuration object are valid will it be added to the list. A valid dimension information usually contains the field value (such as "Marketing Department") and the configuration object (such as {id: "1001", name: "Organizational Structure", parentID: "-2"}).
[0056] 3.2 Handling dimensionless data (boundary case) During the traversal process, 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 string, or their corresponding config objects are invalid), this boundary processing flow is triggered.
[0057] At this time, the system will create a root node with a dimension name of a predefined root identifier. The "predefined root identifier" is preferably obtained from the rootNodeName parameter in the configuration object (e.g. rootNodeName: "Total"), and if not specified, the default identifier (such as "Root Node") is used.
[0058] The core attributes of this special root node are set according to the standardization rules: dimName: set to the above predefined root identifier (such as "Total").
[0059] dimId: set to a predefined unique identifier (such as "root_default" or "-1").
[0060] dimValue: set to the same display value as dimName.
[0061] level: set to 1, representing the top root node level (or can be set to 0 according to the overall level design).
[0062] rowIndex: kept as the index of the current dimensionless data row in the original data array to maintain the association with the original data.
[0063] _fullPathKey: A unique path key generated based on dimId (e.g., "root_default").
[0064] children: Initialized as an empty array for potential natural children nodes to be mounted later.
[0065] isDrillable: Set to false by default, not treated as an expandable node.
[0066] Upon creation, the created root node is immediately added to the root node array (tree). This mechanism ensures that even when facing irregular or completely dimensionless raw data rows, the tree construction process can continue and assign a logically reasonable display position, significantly enhancing the robustness and fault tolerance of the entire method.
[0067] 3.3 Determine the target dimension and create node base information For rows containing valid dimensions, the core of this step is to create a node for the last dimension. Specifically: Get 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 selected because it represents the "leaf" or finest-grained information of the data row in the multi-dimensional path.
[0068] Build node base attributes: dimName: The name of the target dimension (e.g., "dim3").
[0069] dimId: The unique ID of the target dimension, taken from targetDim.config.id.
[0070] dimValue: The display value of the target dimension, i.e., the value of the corresponding field in the original data.
[0071] level: Node level, equal to the length of the dimension list (e.g., dims length is 3, then level is 3).
[0072] rowIndex: The index of the current row in the original data array. This attribute is crucial as it establishes a direct and stable association between the node and the original data row, serving as the cornerstone for subsequent data access and editing synchronization.
[0073] 3.4 Generate path key The path key is the global unique identifier of the node and is also the key to achieving O(1) time complexity for subsequent parent node lookup. The path key generation process is shown in Figure 2 , and the specific execution steps are as follows: 3.4.1 Determine the current dimension ID: get id from the configuration of target dimension (targetDim) as the current dimension ID (currentDimId), i.e. currentDimId = targetDim.config.id.
[0074] 3.4.2 Generate the parent path key (parentPathKey): generated 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. dims[0].config.id to dims[dims.length-2].config.id) in dimension order with underscore "_".
[0075] Edge case: if the length of dimension list is 1 (i.e. there is no dimension before the last dimension), then parentPathKey is an empty string ("").
[0076] Formula: parentPathKey = (dims.length >= 2)? dims[0].config.id + "_" +... + dims[dims.length-2].config.id : "".
[0077] Example: for dimension ID sequence ["1001", "1014", "prodX"], the parentPathKey of "prodX" node is "1001_1014".
[0078] 3.4.3 Generate the full path key (fullPathKey): concatenate the parent path key with the current dimension ID to generate the full path key as the unique identifier of the node.
[0079] Rule: if parentPathKey is not empty, then fullPathKey is parentPathKey + "_" + currentDimId; if parentPathKey is empty, then fullPathKey is currentDimId.
[0080] Formula: fullPathKey = parentPathKey? ${parentPathKey}_${currentDimId} : currentDimId.
[0081] Example: The parentPathKey is "1001_1014", the current dimension ID is "prodX", then the fullPathKey is "1001_1014_prodX".
[0082] The parent path key is empty, and the current dimension ID is "1001", so the fullPathKey is "1001".
[0083] 3.4.4 Storing the path key: The generated fullPathKey is stored in the _fullPathKey attribute of the node object (i.e., node._fullPathKey = fullPathKey). This key is not only the globally unique identifier of the node, but also contains hierarchical path information, which is the core data basis for subsequent implementation of instantaneous parent node lookup, establishment of parent-child relationship, and support for dynamic interactive positioning.
[0084] 3.5 Building a complete node object and determining the type Based on the above information, create a node object (node). Then, by querying the drillable dimension set (drillableDimsSet) initialized in S2, determine whether the current node is a drillable node: isDrillable = drillableDimsSet.has(node.dimName).
[0085] According to the node type, supplement differentiated attributes: Normal node (isDrillable is false): mainly used to form a natural hierarchy. Its basic attributes include dimName, dimId, dimValue, level, rowIndex, _fullPathKey, and an empty children array is initialized to store natural child nodes.
[0086] Drillable node (isDrillable is true): In addition to all the basic attributes and children array of normal nodes, it also has attributes for controlling its expansion and contraction state, mainly including: parentID: taken from targetDim.config.parentID, used to establish the parent-child association of drillable levels within the same dimension.
[0087] drillLevel: drill level, initial value is 0.
[0088] hasDrillChildren: indicates whether there are drillable child nodes, initially false.
[0089] drillChildrenLoaded: indicates whether the drillable child nodes have been loaded, initially false.
[0090] drillChildren: drillable child node array, initially empty.
[0091] 3.6 Store node information to working containers Immediately after node creation, store the two core working containers initialized in S2 to support subsequent processes: Store path key mapping (nodesByPath): Set the node object node as the value with fullPathKey as the key, execute nodesByPath.set(fullPathKey, node). This operation is the basis for achieving O(1) time complexity parent node lookup, completely avoiding recursive traversal.
[0092] Store all node information array (allNodes): Push a tuple containing the build context into the array to provide data sources for the next phase of batch relationship establishment. The tuple usually contains: {node: node, parentPathKey: parentPathKey, fullPathKey: fullPathKey, isDrillable: isDrillable}.
[0093] Through S3, this method systematically converts each row of flat data into a precisely defined node. Each node not only carries the basic information needed for display, but also obtains precise "coordinates" in the tree space through a unique path key, and establishes a direct "anchor point" with the source data through the original data row index. The standardized node set and efficient query mapping (nodesByPath) produced by this step lay the data foundation for completing complex parent-child relationship assembly in a short time in the next phase.
[0094] S4: Establish node relationship and build a two-channel tree structure This step (S4) is the final assembly link of tree structure construction, and its core purpose is to establish the hierarchical relationship between nodes by traversing all nodes built in S3 twice, according to the differentiated rules of node types (normal nodes / expandable nodes), using path key mapping and caching mechanism to quickly find parent nodes, and finally forming a two-channel tree structure containing "natural hierarchy" and "expandable hierarchy". This step is the key to solving the problem of traditional solutions that cannot support multi-dimensional independent expansion and contraction.
[0095] 4.1 Node type definition and two-channel structure overview Before detailing the relationship establishment process, first clarify the two types of nodes defined by this method and their roles in the two-channel structure: Common node: used to represent the hierarchical relationship naturally formed according to the order of dimension fields in the original data, constituting the static trunk of the tree structure. The order of the appearance of the dimension fields in the data row (corresponding to the order of the table columns) implicitly defines its hierarchy. For example, for data with the dimension order of dim1 (department), dim2 (employee), and dim3 (product), the common node corresponding to the latter dimension field is logically a child node of the common node corresponding to the former dimension field. The parent-child relationship is managed through the children array of the parent node.
[0096] Expandable node: used to represent the interactive relationship that can be dynamically expanded or collapsed based on the parent node identifier (parentID) within the same dimension, which is the core of realizing user interactive data drilling. Such a node is associated with a set of attributes (such as parentID, drillLevel, hasDrillChildren, drillChildren, etc.) that are specifically used to control its expansion and collapse state. The parent-child relationship is established by first searching for the parent node in the same dimension according to the parentID.
[0097] Through the differentiated design of the above two types of nodes, this method aims to build a dual-channel tree structure: the natural hierarchical channel maintained by the children pointer, and the expandable hierarchical channel maintained by the drillChildren pointer (and the drillChildrenMap mapping).
[0098] 4.2 Step overview and initialization preparation This step takes the allNodes array output by S3 as the traversal source, which stores the complete construction information tuple of all nodes: {node, parentPathKey, fullPathKey, isDrillable}. Before traversal, the system ensures that the following core data structures are ready: tree: root node array, used to accommodate top-level nodes.
[0099] nodesByPath: path key to node information mapping, which is the basis for O(1) lookup.
[0100] drillChildrenMap: expandable child node mapping, specifically used for temporarily storing expandable child nodes in the lazy loading mode.
[0101] drillableDimsSet: expandable dimension set, used to assist in verifying node types.
[0102] Meanwhile, a temporary parent lookup cache (parentLookupCache) is initialized as a Map to store the completed lookup results, avoiding repeated queries to the nodesByPath map, thus improving the construction performance.
[0103] 4.3 Efficient parent lookup process based on cache mechanism The system sequentially traverses the allNodes array. For each item, its node object, parentPathKey, fullPathKey, and isDrillable flag are extracted. The core of finding the parent node is to combine the O(1) query of the nodesByPath map and cache optimization. For expandable nodes, two-stage lookup logic is used, and the entire process follows the cache-first principle: Step 1: Determine the lookup stage and generate the cache key According to the node type and state, determine the current lookup stage and generate the corresponding cache key (cacheKey): A. Normal node: Directly enter the "natural hierarchical lookup" stage, and use its parentPathKey as the cache key.
[0104] B. Expandable node: (a) Preferential lookup stage: First, try to find the "drill-down parent node" within the same dimension according to its explicitly configured parent node ID (parentID). The cache key generated for this stage is the combination of its parentPathKey and parentID (use only parentID if parentPathKey is empty), i.e., parentPathKey?\${parentPathKey}:\${node.parentID}:\${node.parentID}.
[0105] (b) Bottom-up lookup stage: If the parent node is not found through the parentID, fall back to the "natural hierarchical lookup" stage, i.e., find the parent node according to its parentPathKey. The cache key for this stage is its parentPathKey.
[0106] Step 2: Cache hit judgment Query the parentLookupCache to see if there is a record corresponding to the current cacheKey. If it exists (cache hit), directly get the cached parent node information (parent node object or null) without accessing the nodesByPath map.
[0107] Step 3: Map lookup execution If cache miss, perform actual lookup in nodesByPath map with the lookup key determined in current lookup phase: "Natural Hierarchy Lookup": lookup key is parentPathKey, perform parentNode = nodesByPath.get(parentPathKey).
[0108] "Explicit Association Lookup": lookup key is the combination of parentPathKey and parentID (e.g. \${parentPathKey}_\${node.parentID}), perform corresponding query.
[0109] Step 4: Cache update Store the lookup result (found parent node object or null) of step 3 into parentLookupCache with cacheKey as key for later reuse.
[0110] This mechanism ensures that multiple queries for the same lookup key only need to perform the actual map query once, and subsequent lookups are cache access with O(1) time complexity, greatly improving the construction efficiency.
[0111] 4.4 Differentiated processing logic for node relationship establishment According to the isDrillable identifier and the lookup result, the system performs completely different relationship establishment logic for two types of nodes: 4.4.1 Processing of ordinary nodes (establishing natural hierarchy) 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 dimension path and should be treated as a top-level node. It is directly added to the tree root array.
[0112] Rule 2 (lookup success): If the parent node is successfully found through the cache mechanism, the current ordinary node is treated as a child node and is mounted to the children array of the parent node, thereby establishing the natural hierarchy relationship of the dimension.
[0113] Rule 3 (lookup failure): If the found parent node is null (i.e. lookup failure), perform degradation processing and add the node as a root node to the tree array to ensure the integrity of the tree structure.
[0114] 4.4.2 Processing of expandable nodes (establishing expandable hierarchy) The prerequisite for processing expandable nodes is that isDrillable is true, and the parentID attribute of the node exists and is valid (not "-2" or other root identifiers).
[0115] 4.4.2.1 Finding and Locating: The system first enters the priority finding phase, trying to locate the "drill-up parent node" in the same dimension by combining the finding key formed by its parentPathKey and parentID. If found, it is processed differently according to the configured loading mode; if not found, it enters the bottom-up finding phase and instead looks for the parent node through its parentPathKey. If found in the bottom-up phase, it is mounted as a normal child node to the parent node's children array; if still not found, it performs a degradation process and adds the node to the tree array as a root node.
[0116] 4.4.2.2 Differentiated Loading and Mounting (according to the lazyLoadDrillChildren configuration): Lazy loading mode (lazyLoadDrillChildren: true): When the parent node is found through the parentID, the current expandable node is not directly mounted under the parent node, but is temporarily stored in the drillChildrenMap. The _fullPathKey of the parent node is used as the key, and the node is added to the corresponding child node array. At this time, the hasDrillChildren attribute of the parent node is marked as true, and the drillChildrenLoaded is false. The child node will be dynamically loaded when the user first expands.
[0117] Immediate loading mode (lazyLoadDrillChildren: false): When the parent node is found through the parentID, the current expandable node is directly added to the drillChildren array of the parent node. At the same time, set the drillLevel of the current node to drillLevel+1 of the parent node, and set the hasDrillChildren and drillChildrenLoaded attributes of the parent node to true.
[0118] 4.5 Final formation of the double-channel tree structure When all nodes in the allNodes array are processed: Natural hierarchical tree: All normal nodes are connected to each other through the children pointer, starting from the tree array, forming a complete natural hierarchical tree that reflects the dimension order.
[0119] Expandable hierarchical network: all expandable nodes, according to configuration, are either directly mounted into the parent node's drillChildren array (immediate loading mode) or temporarily categorized in the drillChildrenMap (lazy loading mode), forming an interactive network independent of natural hierarchy, supporting dynamic expansion and folding.
[0120] So far, a logically complete two-channel tree data model has been built. allNodes and nodesByPath, as temporary data structures during the construction period, have all their contents transferred and associated to the final tree model. They will be cleaned up in the subsequent steps.
[0121] Through S4, the invention efficiently and accurately builds a two-channel tree structure. The children channel maintains a stable natural hierarchy, ensuring the structured display of basic data; the drillChildren channel (and drillChildrenMap) manages flexible expandable hierarchy, providing data support for multi-dimensional independent drilling interaction. The combination of the cache mechanism and O(1) lookup based on path keys makes the overhead of establishing complex parent-child relationships extremely low even when the data volume is extremely large. The final tree structure is clear, well-defined, and highly expandable, laying a solid data foundation for subsequent high-performance table rendering and smooth interaction experience.
[0122] S5: Clean up temporary data and return the core result object This step (S5) is the end and output link of the tree structure construction process. After successfully building a complete two-channel tree logical structure in S4, this step aims to perform resource recycling and result packaging: systematically clean up temporary data structures used only during the construction period to release memory, and package the final stable and usable core data model as a standardized result object for return, providing efficient and clear data input for subsequent table rendering and interaction control.
[0123] 5.1 Step goal and input context The input of this step is the working context after complete processing from S1 to S4, at which time the two-channel tree structure has been logically established through the children and drillChildren (or drillChildrenMap mapping) pointers between nodes. The core operation goal of this step has two: Cleanup: identify and release intermediate or temporary data containers that are no longer directly dependent after the tree structure is established, optimize overall memory usage efficiency, and improve the running stability of the application when processing large-scale data.
[0124] Packaging and Return: The parts of the construction result that are necessary for the subsequent processes (table row construction, rendering, interaction) are organized into a clearly structured, single-responsibility result object, which is the main output of this method and provides a standardized data interface for downstream modules.
[0125] 5.2 Identification and cleanup of temporary data structures During the construction process, some data structures play the role of "scaffolding", whose main mission ends when the parent-child relationship is established. After ensuring that all nodes have established parent-child relationships, the system actively cleans up these temporary data, which is a manifestation of the invention's fine-grained performance considerations. Temporary data that needs to be cleaned up mainly includes: 5.2.1 allNodes array: Purpose: Stores all node construction information tuples in S3 phase, providing a linear traversal source for batch establishing parent-child relationships in S4 phase.
[0126] Reason for cleaning up: All node information has been associated with the final tree structure through pointers (children, drillChildren), and this array is no longer accessed.
[0127] Cleaning method: Empty the array or set its reference to null to allow the garbage collection mechanism (Garbage Collection) to reclaim the occupied memory.
[0128] 5.2.2 nodesByPath mapping (path key to node information): Purpose: In S3 and S4 phases, store nodes with fullPathKey as key, which is the core data structure for achieving O(1) time complexity parent node lookup.
[0129] Reason for cleaning up: After the tree relationship is established, depth-first traversal through the root node array (tree) is the standard node access method, and the reverse lookup function of this mapping is no longer needed in subsequent processes.
[0130] Cleaning method: Empty the mapping and release the reference.
[0131] 5.2.3 parentLookupCache: Purpose: Temporary cache (Map type) introduced in S4 phase for performance optimization, used to store completed parent node lookup results to avoid repeated queries to the nodesByPath mapping.
[0132] Reason for cleaning up: Once the parent-child relationship between nodes is established, the data in this cache is immediately invalidated.
[0133] Cleanup: Clear the cache map.
[0134] 5.3 Packaging and definition of core result object After the cleanup, the system will package the persistent part of the result into a structured result object (named treeCoreResult). This object is the only output of the method (createDrillableTree) and is the only data source for all subsequent processes. Its design follows the principle of "minimum and sufficient" to ensure clear and efficient interfaces.
[0135] A complete core result object contains the following attributes, as shown in Table 1:
[0136] 5.4 Result return and process end Finally, the main construction method is executed and returns the packaged core result object, marking the completion of the multi-dimensional tree table control data construction phase.
[0137] At this point, the caller obtains a pure, two-channel tree model (tree) containing complete logical relationships, an interactive data pool (drillChildrenMap) that supports on-demand loading, and necessary control parameters (maxDimension, drillableDims). This structured treeCoreResult object lays a solid and efficient data foundation for subsequent efficient, smooth table row data construction, visualization rendering, and user dynamic interaction. By actively cleaning up temporary data, the invention not only provides powerful functions, but also significantly optimizes memory usage efficiency.
[0138] S6: Construction of table row data and rendering This step (S6) is the key conversion link between the data model and the final visual display. Its core purpose is to convert the two-channel tree structure returned by S5 into a flat, sequential two-dimensional table row data set based on the tree structure core result object, and finally complete the rendering and drawing of the table, achieving precise mapping from logical tree to visual table.
[0139] 6.1 Core input and step goal The inputs of this step mainly include: 6.1.1 The treeCoreResult core result object returned by S5, which includes the following key components: tree: Root node array, serving as the starting point for traversal, containing complete two-channel hierarchical relationships.
[0140] maxDimension: The maximum dimension level, used to control the number of table dimension columns displayed.
[0141] drillableDims: An array of expandable dimension names, used to identify interactive nodes.
[0142] 6.1.2 The original data array originTableDatas acquired by S1, used to extract business indicator data.
[0143] The core goal of this step is: Data conversion: Convert the nested tree structure into a linear row data array by traversing.
[0144] Data enrichment: Fill in complete dimension values, business indicators, and control rendering meta-information for each row of data.
[0145] View generation: Trigger front-end rendering logic to convert data into a user-viewable table.
[0146] 6.2 Depth-first traversal to generate flat row data The system starts with the treeCoreResult.tree array and performs depth-first traversal (DFS), recursively accessing the child nodes of each node to generate a flat table row data set (tableRowDataList).
[0147] Traversal rules: 6.2.1 When accessing a node, first generate the row data corresponding to the node.
[0148] 6.2.2 Then, recursively process all child nodes (natural level) in the children array.
[0149] 6.2.3 Key limitations: During the initial traversal, do not access expandable child nodes that are in the collapsed state (i.e., all drillChildren arrays). Only when the user subsequently triggers interactive expansion will these child nodes be dynamically loaded and accessed, ensuring the efficiency of initial rendering.
[0150] After traversal, tableRowDataList forms a flat array, whose order strictly corresponds to the depth-first traversal order of the tree structure, providing a data basis for subsequent table rendering.
[0151] 6.3 Single row data construction process For each node accessed in the traversal, the buildRowDataForNode function is responsible for constructing its corresponding table row data object. This process integrates the conversion of all attributes required for rendering from node information: 6.3.1 Determine the level and path: The level of a node can be obtained directly from its level attribute, or by parsing its full path key (_fullPathKey): split the _fullPathKey with the underscore "_" as the delimiter, and count the length of the array after splitting, which is the exact depth of the node in the dimension hierarchy. For example, _fullPathKey="1001_1014_prodX" splits to ["1001", "1014", "prodX"], and the array length is 3, indicating that the node is at the third level. The pathContext parameter can be used to maintain ancestor path information to assist in calculation.
[0152] 6.3.2 Extract and fill dimension values: Each node only stores its own dimension (dimValue). To generate a complete table data with maxDimension dimension columns in a row: For dimension columns less than or equal to the current node level, the actual dimension value needs to be filled in. This is usually obtained by querying the ancestor path information of the node or backtracking the parent node chain. For example, a third-level "Product X" node, its first and second dimension columns of the row need to be filled with its "Department A" and "Employee 1" respectively. For dimension columns beyond the current node level, fill in placeholders (such as "-").
[0153] 6.3.3 Associate and fill in indicator data: The core operation is to use the row index (original data row index) saved in the node to directly index the original data array originTableDatas, and instantly get all business indicators of the row. This mechanism ensures a one-to-one correspondence between table row data and original business data row, which is the basis for subsequent data editing synchronization.
[0154] 6.3.4 Generate rendering and interactive control meta information: In addition to containing dimension values and indicator values, the constructed row data object also needs to embed the following key meta information: Merged cell identifier (dimMerge): Calculate an identifier for each dimension cell (usually based on its parent path key parentPathKey). When rendering, adjacent cells with the same dimMerge identifier can be merged (by setting rowspan) to achieve the visual grouping effect of tree structure.
[0155] Node object reference: In the row data, or in the specific dimension column cell data of its current node, associate the node object itself. This is the core bridge for quickly locating the corresponding tree node when implementing click expansion, editing and other interactive functions.
[0156] indentControlInfo: Calculate the indent amount according to the drillable level of the node, achieve the effect of the larger the drillable level, the larger the visual indentation, used to distinguish different depth of drilling nodes when front-end rendering.
[0157] interactionStateInitialization: Mark whether the node corresponding to this row is an expandable node (isDrillable), and initialize interaction control attributes such as foldCount: 0 (fold count), nextRow: null (next row reference), isExpanded: false (expanded state), to prepare for efficient interaction in S7 step.
[0158] 6.4 Table rendering After traversal is completed, tableRowDataList constitutes a flat, sequential table row data set. The front-end rendering component (based on native DOM, Canvas, or modern front-end framework) renders a multi-dimensional tree table with hierarchical structure based on this set.
[0159] The rendering process mainly includes: 6.4.1 Table header generation: dynamically generate column titles of the table according to maxDimension and predefined business indicator fields.
[0160] 6.4.2 Row traversal and creation: loop through tableRowDataList to create corresponding table rows (HTML elements) for each row data object.
[0161] 6.4.3 Cell filling and style setting: Create dimension column and indicator column cells (HTML elements) for each row.
[0162] Fill the dimension text and indicator text in the row data into the corresponding cells.
[0163] Apply the calculated style, such as padding-left to achieve hierarchical indentation.
[0164] According to the dimMerge identifier, set the rowspan attribute for adjacent cells that need to be merged vertically.
[0165] 6.4.4 Interaction control binding: Add an expand / collapse icon (such as "+" / "-" ) in the dimension cell or front of the expandable node (isDrillable is true).
[0166] Bind the click event of this icon to the associated node object in the row data, so that it can quickly locate the corresponding tree node and its data when interacting.
[0167] 6.4.5 Mounting and rendering: Mount the entire table DOM tree with rendering completed into the designated container element of the page, and finally render it to the user.
[0168] Through the S6 step, the present application efficiently completes the conversion from the complex double-channel tree model to the visual table. The process deeply depends on and embodies the advantages of the previous design: the direct association with the original data is realized by using rowIndex; the hierarchical and merging logic is accurately derived by using the path key system; and the efficient rendering of the initial state is realized by distinguishing between children and drillChildren. The generated two-dimensional row data not only contains the display content, but also embeds complete control element information and node references, providing sufficient and structured data preparation for the next stage of dynamic and high-performance expansion and collapse interaction (S7), and finally presenting a multi-dimensional tree table with clear hierarchy, accurate data, and ready-to-use interaction.
[0169] S7: User dynamic expansion and collapse interaction As shown in Figure 3 , this step (S7) is the key link to realize the core interactive function of the multi-dimensional tree table. Based on the initial rendering of the table completed in S6, this step responds to user operations on expandable nodes, and based on the innovative "inter-row reference association" and "folding count control" cooperative mechanism, it dynamically loads, inserts, hides, or displays the row data corresponding to the child nodes under it, 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 delayed response in traditional solutions, and achieving instantaneous response to expansion and collapse operations in scenarios of arbitrary depth and nesting.
[0170] 7.1 Interaction basis and state initialization The interactive function is built on 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, which constitute the data basis for all subsequent interaction logic, as shown in Table 2:
[0171] All drillChildren child node rows of expandable nodes are not inserted into tableRowDataList at the beginning, and are in an unloaded or to-be-loaded state.
[0172] 7.2 First expansion operation: child node loading and row insertion When the user first clicks on an expandable node row in the collapsed state (icon "+") (denoted as row A), the system performs the following process: 7.2.1 Data fetching: Fetch child node data of targetNode according to the configured loading mode.
[0173] Lazy loading mode: Take the temporary child node array from treeCoreResult.drillChildrenMap in S5 with targetNode._fullPathKey as key.
[0174] Immediate loading mode: Fetch child nodes directly from targetNode.drillChildren array.
[0175] 7.2.2 Child row data generation: Traverse each child node fetched and call similar row construction method as S6 to generate corresponding table row data object. Initialize foldCount as 0 in newly generated child row data and establish association with parent row A.
[0176] 7.2.3 Row data and DOM insertion: In tableRowDataList array, find A row and its nextRow reference pointing to the original next row (denoted as B row, i.e. A.originalNextRow).
[0177] Insert generated child row data in order after A row and before B row.
[0178] In table DOM, insert newly generated child row elements after the element corresponding to A row.
[0179] 7.2.4 Row reference relationship update: Update A row reference: Update nextRow of A row to point to the index of the first newly inserted child row.
[0180] Establish child row reference chain: Establish nextRow reference chain among newly inserted child rows so that the last child row's nextRow points to the original B row.
[0181] 7.2.5 State update: Set isExpanded state of A row to true and update the expansion icon to "-".
[0182] (Lazy loading mode) Officially mount child nodes to targetNode.drillChildren array and set drillChildrenLoaded to true.
[0183] 7.3 Collapse operation: Hide child rows through fold count When a user clicks on a row (row A) that is already expanded (icon is "-"), the collapse flow is executed: 7.3.1 Range Locating: Starting from A.nextRow, iterate through the nextRow reference chain until the originalNextRow of row A (i.e. row B) is reached. This range precisely contains all direct and indirect children of row A that need to be collapsed.
[0184] 7.3.2 Fold Count Updating: Increment the foldCount attribute of each row in the range by 1.
[0185] 7.3.3 View Updating: Immediately hide (e.g. display:none) the DOM element corresponding to each row in the range according to the rule "if foldCount > 0 then hide".
[0186] 7.3.4 State Resetting: Set the isExpanded state of row A to false and switch the icon back to "+".
[0187] 7.4 Re-Expansion: Displaying children via fold count When a user clicks on a row (row A) that is already collapsed but its children are loaded (isExpanded is false but drillChildrenLoaded is true), the re-expansion flow is executed: 7.4.1 Range Locating: Same as the collapse flow, iterate through the nextRow reference chain until the originalNextRow is reached.
[0188] 7.4.2 Fold Count Updating: Decrement the foldCount attribute of each row in the range by 1.
[0189] 7.4.2 View Updating: Check the foldCount value of each row.
[0190] If foldCount is equal to 0 after decrementing, show (e.g. display: '') the DOM element corresponding to the row.
[0191] If foldCount is still greater than 0 (e.g. the row itself is a collapsed parent), keep the row hidden.
[0192] 7.4.4 State Resetting: Set the isExpanded state of row A to true and switch the icon to "-".
[0193] 7.5 Control Mechanism for Nested and Independent Expansion The "fold count" and "row reference" mechanism naturally supports complex interaction scenarios: Nested expansion / collapsing: Suppose row A has child row C under it, and C has grandchild row D under it. When row A is collapsed, both C and D have their foldCount incremented by 1 and are hidden. When row A is expanded again, both C and D have their foldCount decremented by 1. At this point, row C has its foldCount back to 0 and is shown, but row D remains hidden because row C might still be in a collapsed state (foldCount comes from the operation of row C), and its foldCount is still greater than 0. This perfectly matches the user's intuitive expectation of collapsing nested levels.
[0194] Independent control within the same level: Multiple expandable child nodes under the same parent node can be independently expanded or collapsed without interfering with each other, as they each have their own independent foldCount state and nextRow reference chain.
[0195] 7.6 Summary of technical effects Through the interaction mechanism achieved by S7, the present application brings significant performance and experience improvement: Extreme interaction performance: The expansion and collapse operation only needs to be performed through local linear traversal of the nextRow reference chain, with a time complexity of O(k) (k is the number of directly affected rows), and only the foldCount and a small number of DOM element display states are updated, completely avoiding the overhead of recursive traversal of the entire tree (O(N)) or large-scale DOM operations in traditional solutions.
[0196] Precise state management: The "fold count" model clearly encodes the row's display and hiding logic with a simple integer property, with rigorous logic that perfectly supports nested expansion of any depth and independent control of sibling nodes.
[0197] Efficient rendering update: View updates are data-driven, with only minimal DOM operations (display / hide) performed on affected rows, greatly reducing browser reflow (Reflow) and repaint (Repaint).
[0198] Smooth user experience: The above technical optimizations ultimately translate into "instant response" in user perception, even with massive, deep, and multi-dimensional data, the expansion and collapse operations have no lag.
[0199] So far, combining the complete process of S1 to S7, the present application realizes a full-link closed loop from flat data acquisition, double-channel tree construction, efficient rendering of tables, to high-performance interaction, providing a multi-dimensional tree table control generation method that is complete in function, outstanding in performance, and smooth in user experience.
[0200] Figure 4 A structural schematic diagram of a multi-dimensional tree table control generation device. As Figure 4 As shown, the multi-dimensional tree table control generation apparatus 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 returning module 205, a table rendering module 206, and an interactive control module 207.
[0201] The data acquisition module 201 is configured to acquire an original data array issued by a background, an expandable dimension name array, a maximum dimension level, and a configuration object, wherein the original data array is a flattened data array, each row of data contains multiple dimension fields and corresponding configuration information, and the configuration object is used to control the construction and interaction behavior; The structure initialization module 202 is configured to initialize a data structure, wherein the data structure includes a root node array, an all-node information array, a path key to node information mapping, an expanded child node mapping, and an expandable dimension set; The node construction module 203 is configured to traverse data to construct 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, and generating a parent path key, then generating a complete path key as a unique identifier of the node based on the parent path key, and finally storing the created node information into the path key to node information mapping and the all-node information array with the path key as the key; The relationship establishment module 204 is configured to quickly find the parent node in the path key to node information mapping according to the parent path key of the two types of nodes constructed respectively, and establish the parent-child relationship, and finally all nodes form a double-channel tree structure containing natural levels and expandable levels according to their types and paths, wherein the two types of nodes are divided into ordinary nodes and expandable nodes; The data cleaning and returning module 205 is configured to clean up temporary data and return a tree structure core result object; The table rendering module 206 is configured to traverse and recursively traverse the root node array based on the returned tree structure core result object, construct row data, and traverse the row data for table rendering; The interactive control module 207 is configured to support user dynamic expansion or folding interaction on the rendered table.
[0202] On the basis of the above embodiment, the data acquisition module 201 can be specifically used to acquire the flattened original data array from a backend service interface, and parse and acquire the expandable dimension name array, the maximum dimension level, and the configuration object containing the lazy loading mode and the like.
[0203] On the basis of the above embodiment, the structure initialization module 202 can be specifically used for: initializing the root node array, the all node information array, the path key to node information mapping, the expanded child node mapping, and the expandable dimension set, to provide a basic data container for subsequent tree structure construction.
[0204] On the basis of the above embodiment, the node construction module 203 can be specifically used for: traversing each row of the original data array, extracting all valid dimension fields and their configuration information; creating a node object for the last dimension of each row, saving the original data row index, and setting the node basic attributes; generating a parent path key and a complete path key based on the extracted dimension information, as the node unique identifier; storing the node information into the path key to node information mapping and the all node information array.
[0205] On the basis of the above embodiment, the relationship establishment module 204 can be specifically used for: quickly finding the parent node of each node through the cache mechanism and the path key mapping; according to the node type, mounting the normal node to the child node array of the parent node, and mounting the expandable node to the expanded child node array of the parent node according to the lazy loading configuration or temporarily storing it in the expanded child node mapping; performing degradation logic on the node whose parent node is not found, and processing it as a root node.
[0206] On the basis of the above embodiment, the data cleaning and returning module 205 can be specifically used for: cleaning the temporary data structure used in the construction process, releasing the memory; and encapsulating and returning the tree structure core result object, which at least contains the root node array, the expanded child node mapping, the maximum dimension level, and the expandable dimension name array. On the basis of the above embodiment, the table rendering module 206 can be specifically used for: based on the returned tree structure core result object, traversing and recursively the root node array in a depth-first manner to construct a flat table row data set; and according to the table row data set, rendering a multi-dimensional tree table with a hierarchical structure. On the basis of the above embodiment, the interaction control module 207 can be specifically used for: in response to the user's expansion operation on the table row, obtaining the child node data from the expanded child node mapping according to the complete path key of the node, generating and inserting the corresponding table row data, and establishing the reference relationship between rows; in response to the user's folding operation on the table row, traversing the affected sub-row range according to the inter-row reference relationship, updating the folding count and controlling the display or hiding state of the related rows, wherein the row is displayed when the folding count is 0, and the row is hidden when the folding count is greater than 0.
[0207] In summary, the multi-dimensional tree table control generation device provided in the embodiment provides the following advantages. The data acquisition module standardizes the original data and configuration parameters required for constructing a multi-dimensional table. The structure initialization module builds a unified data storage carrier. The node construction module creates a basic node and generates a unique identifier. The relationship establishment module quickly constructs a double-channel tree structure with natural levels and expandable levels through reiteration and path key mapping. The data cleaning and returning module optimizes memory occupation and outputs a standardized core result object. The table rendering module realizes the conversion of the tree structure to a visual table. The interactive control module supports the core interactive needs of the user, such as dynamic expansion and folding, based on inter-row referencing and folding counting. Through the synergistic effect of the above modules, the problems of multi-dimensional display confusion and low interaction efficiency of the traditional tree table control are solved. The structured hierarchical display and efficient dynamic interaction of multi-dimensional data are realized. The user can intuitively view the hierarchical relationship of multi-dimensional table data, and the user experience in the enterprise-level data analysis scene is improved.
[0208] It should be noted that the units and modules included in the above embodiment of the multi-dimensional tree table control generation device are only divided according to the functional logic, but are not limited to the above division, as long as the corresponding functions can be realized. In addition, the specific names of the functional units are only for easy mutual distinction, and do not limit the protection scope of the present application.
[0209] Those skilled in the art should understand that the above discussion of any embodiment is only exemplary and is not intended to limit the scope of the embodiments disclosed by the present application (including the claims); under the idea of the embodiments of the present application, the technical features of the above embodiments or different embodiments can also be combined, and there are many other changes of different aspects of the embodiments of the present application as described above. In order to be brief, they are not provided in details. Therefore, any omission, modification, equivalent replacement, improvement, etc. made in the spirit and principles of the embodiments of the present application shall be included in the protection scope of the embodiments of the present application.< / 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. 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 process 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: 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.
5. 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.
6. 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.
7. The method for generating a multi-dimensional tree table control according to claim 6, 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.
8. The method for generating a multi-dimensional tree table control according to claim 7, 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.
9. 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.
10. A method for generating a multi-dimensional tree table control according to claim 9, 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.
11. The method for generating a multi-dimensional tree table control according to claim 10, 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.
12. 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. 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.
Citation Information
Patent Citations
Tree form control generation method and device, equipment and storage medium
CN113504901A
High-performance virtual scrolling method and system supporting large-scale tree structure
CN121300783A
Searching method for ontology information using keyword and device thereof
KR1020100077923A
Mapping an Object Type to a Document Type
US20120254719A1
Grouping expanded and collapsed rows in a tree structure
US20130007658A1
Cited By
Interaction method and device for data structure visualization supporting infinite nesting
CN121996120A