Table rendering method, system and device based on immutable column configuration metadata

Abstract

The embodiment of the application aims to provide a table rendering method, system and device based on immutable column configuration metadata, wherein the method comprises: performing a shallow freeze on each column configuration metadata object to obtain an immutable column configuration metadata array; parsing the immutable column configuration metadata array, traversing and extracting key fields to form a standardized immutable column configuration metadata set; identifying columns containing a filter type mark, deducing a filter interaction component and a request parameter mapping relationship based on the filter type mark, and initializing a filter value state; obtaining a current paging state and a current sorting state maintained by a table component, assembling a request parameter according to the current paging state, the filter value state and the current sorting state, calling a data interface to obtain a table data list; and generating a final column definition set based on the immutable column configuration metadata set, and inputting the final column definition set, the table data list and the current paging state into the table component for rendering.

Description

Technical Field

[0001] This invention relates to the field of form processing technology, and in particular to a table rendering method, system, and device based on immutable column configuration metadata. Background Technology

[0002] In existing technologies, table column configurations are typically defined directly in the business code as arrays of mutable objects. Developers often don't constrain these column configuration objects after creation, and subsequent business logic, state management code, or third-party plugins may modify their properties—for example, by replacing rendering functions at runtime, changing column headers, or adjusting sorting tags. Because these objects lack reference stability throughout the rendering lifecycle, declarative rendering frameworks cannot quickly determine whether column definitions have changed through simple reference equality checks when performing virtual DOM difference comparisons. Instead, they need to deeply compare the properties of each column configuration object at various levels. This leads to unnecessary computational overhead that amplifies with the number of columns and the frequency of interactions, resulting in rendering performance degradation.

[0003] In implementing filtering functionality, existing technologies also rely on developers manually binding data in multiple locations. For each field requiring filtering capabilities, developers must manually select the appropriate filtering interaction control type based on their understanding of the business data type, such as deciding whether the column should use a dropdown selection control or a date range control. Simultaneously, developers must manually specify the data source interface for the filtering control. When the business scenario changes, such as switching from a list page of one type of resource instance to a list page of another, even if the columns on the two pages have the same semantics, their filter option data source interfaces are often different. Developers need to modify the interface address column by column; even a slight oversight can lead to incorrect or empty filter options. Furthermore, the mapping relationship between the output values ​​of the filtering control and the backend request parameters also entirely depends on developers manually writing conversion code, including parameter key mapping, array splitting of multiple selection values, conversion of the start and end formats of time range values, and handling of null values. These mapping logics are scattered across different code segments during component initialization, event callbacks, and before request initiation. They lack a unified constraint and triggering coordination mechanism. If the mapping logic in one place is inconsistent with the filtering state storage method in another place, the selected value in the filtering interface will not match the request parameters finally sent to the backend, resulting in query results that do not meet the user's expectations.

[0004] The root cause of the above problems lies in the fact that column configuration information and filtering capability binding information exist in the code in a variable, scattered manner and rely on manual maintenance. The configuration objects cannot remain stable at runtime, and there is a lack of a traceable source of declarations between the various stages of the filtering function. This makes it difficult to avoid unnecessary calculations during table rendering, and parameter misalignment is prone to occur in filtering state management, ultimately affecting the overall reliability and interaction efficiency of the table component. Summary of the Invention

[0005] The purpose of this invention is to provide a table rendering method, system, and device based on immutable column configuration metadata. The method in this embodiment can improve the interactive efficiency and configuration reliability of table rendering.

[0006] To address the aforementioned problems, this invention provides a table rendering method based on immutable column configuration metadata, applied to a table rendering system. The table rendering system includes a table component and a filtering interaction component. The method includes: Define a column configuration metadata array. Each column configuration metadata object in the array includes at least a data field identifier, a display title, a filter type marker, and a filter parameter mapping key. Perform a shallow freeze on each column configuration metadata object to obtain an immutable column configuration metadata array. Parse the immutable column configuration metadata array, traverse and extract key fields, and generate unique column identifiers to form a standardized immutable column configuration metadata set. Traverse the immutable column configuration metadata set to identify columns containing the filter type marker. Based on the filter type marker, deduce the mapping relationship between the filter interaction component and the request parameter, bind the filter interaction component to the column header of the corresponding column, and initialize the filter value state. Obtain the current pagination state and current sorting state maintained by the table component. Assemble request parameters based on the current pagination state, the filter value state, and the current sorting state, and call the data interface to obtain the table data list. Based on the immutable column configuration metadata set and the filter interaction component already bound to the column header, generate a final column definition set. Pass the final column definition set, the table data list, and the current pagination state into the table component for rendering.

[0007] This invention also proposes a table rendering system, which includes a table component and a filtering interaction component. The system further includes: The column configuration metadata definition module defines a column configuration metadata array. Each column configuration metadata object in the array includes at least a data field identifier, a display title, a filter type marker, and a filter parameter mapping key. A shallow freeze is performed on each column configuration metadata object to form an immutable column configuration metadata array. The table request processing module parses the immutable column configuration metadata array, iterates through it to extract key fields, and generates unique column identifiers to form a standardized immutable column configuration metadata set. The filter derivation module iterates through the immutable column configuration metadata set, identifies columns containing the filter type marker, and derives filters based on the filter type marker. The system establishes a mapping relationship between the filtering interaction component and request parameters, binds the filtering interaction component to the column header of the corresponding column, and initializes the filtering value state. A data list calling module is used to obtain the current pagination state and current sorting state maintained by the table component, assemble request parameters based on the current pagination state, the filtering value state, and the current sorting state, and call the data interface to obtain the table data list. A table component rendering module is used to generate a final column definition set based on the immutable column configuration metadata set and the filtering interaction component already bound to the column header, and pass the final column definition set, the table data list, and the current pagination state to the table component for rendering.

[0008] This invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0009] This invention achieves the immutability guarantee of column configuration metadata and the declarative deduction of filtering capabilities by defining and freezing column configuration metadata, parsing and generating a standardized immutable set, deriving filtering capabilities based on filtering tags, assembling multi-source state request parameters, and generating and rendering the final column definition set. Since the immutable metadata reference remains stable throughout the rendering lifecycle, unnecessary deep comparisons during the virtual DOM comparison process are reduced. Simultaneously, the filtering type tags eliminate the inconsistency risks associated with manually binding component types, data sources, and parameter mappings, thereby improving the efficiency of table rendering and the maintainability of the configuration. Attached Figure Description

[0010] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0011] Figure 1This is a flowchart illustrating a table rendering method based on immutable column configuration metadata according to the first embodiment of the present invention. Figure 2 This is a flowchart illustrating a table rendering method based on immutable column configuration metadata according to the second embodiment of the present invention. Figure 3 This is a flowchart illustrating a table rendering method based on immutable column configuration metadata according to the third embodiment of the present invention. Figure 4 This is a specific flowchart of step 104 in the fourth embodiment of the present invention; Figure 5 This is a rendering example of the overall interface of an ECS instance list page according to the fourth embodiment of the present invention; Figure 6 This is a rendering example of a floating window interactive interface for column settings according to the fourth embodiment of the present invention; Figure 7 This is an example diagram of a user-defined visible column re-rendering according to the fourth embodiment of the present invention; Figure 8 This is a rendering example of a drop-down filter panel for a cloud region filter column according to the fourth embodiment of the present invention; Figure 9 This is a rendering example of a query condition area above a table according to the fourth embodiment of the present invention; Figure 10 This is a rendering example of a drop-down radio button panel for an instance type filter column according to the fourth embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of a table rendering system according to the fifth embodiment of the present invention; Figure 12 This is a schematic diagram of the structure of the electronic device according to the sixth embodiment of the present invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions of this disclosure, and to fully understand and implement the process of how this disclosure applies technical means to solve technical problems and achieve corresponding technical effects, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. The embodiments of this disclosure and the various features within them can be combined with each other without conflict, and the resulting technical solutions are all within the protection scope of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort should fall within the protection scope of this disclosure.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] The first embodiment of this invention relates to a table rendering method based on immutable column configuration metadata, applied to a table rendering system based on immutable column configuration metadata. The table rendering system includes a table component and a filtering interaction component. The table component displays table data based on a set of column definitions and a data source, while the filtering interaction component provides users with a filtering interface for table columns. In existing technologies, column configurations are typically scattered throughout the business code as arrays of mutable objects. The mapping relationship between the filtering component type, data source, and request parameters relies on manual binding by the developer, which easily leads to inconsistencies in state and rendering performance degradation. This invention freezes the column configuration metadata as immutable objects and automatically derives the mapping relationship between the filtering interaction component and request parameters based on the filtering type markers in the metadata, while maintaining the stability of metadata references throughout the rendering lifecycle. This reduces unnecessary re-rendering and improves the maintainability of the configuration.

[0015] like Figure 1 As shown, the method in this embodiment specifically includes the following steps 101-105: Step 101: Define a column configuration metadata array. Each column configuration metadata object in the column configuration metadata array shall include at least a data field identifier, a display title, a filter type flag, and a filter parameter mapping key. Perform a shallow freeze on each column configuration metadata object to obtain an immutable column configuration metadata array.

[0016] Specifically, each business module defines a column configuration metadata array, `columnsList`. Each column configuration metadata object is a purely descriptive object containing the following declarative fields: `dataIndex` (data field identifier), used to associate the field name in the backend returned data; `title` (display title), used to support internationalized function return values; `isStatusFilter / isCloudRegionFilter / isTimeRangeFilter` (filter type flag), used to declare what type of filtering capability this column needs to be injected; and `filtersKey` (filter parameter mapping key), used to define the parameter name when requesting the filter selection value from the backend. In addition, it may include a `render` (custom rendering function) field, used to transform the raw data into the interface display format; and a `sorter` (sorting flag) field, used to identify whether the column supports frontend or backend sorting. After creation, the attribute values ​​of each column configuration metadata object are either raw values ​​or pure function references. A pure function reference means that the function does not depend on external mutable state, and its output is determined only by the input parameters; therefore, the reference remains stable and has no side effects across multiple calls. A shallow freeze is performed on the metadata object for each column configuration. This can be achieved by freezing the object itself using JavaScript's `Object.freeze()` method, preventing existing properties from being reassigned, deleted, or added, thus creating an immutable array of column configuration metadata. Since the property values ​​are primitive values ​​or pure function references, a shallow freeze is sufficient to meet the immutability requirement, eliminating the need for recursive freezing. Each metadata object in this immutable array is used as read-only source data in subsequent steps. When enhanced configurations need to be generated based on the metadata, a new object is created using the spread operator or `Object.assign`, rather than modifying the original object. No downstream components perform any modification operations.

[0017] Step 102: Parse the immutable column configuration metadata array, traverse and extract key fields and generate unique column identifiers to form a standardized immutable column configuration metadata set.

[0018] Specifically, after obtaining the immutable column configuration metadata array, the unified table request component MonTableWithRequest (i.e., the table component) in the system parses the immutable column configuration metadata array. Since the metadata objects in the original array are frozen, new attributes cannot be directly added to them. Therefore, during the parsing process, this embodiment traverses each frozen column configuration metadata object, extracts key fields such as data field identifiers, display titles, filter type markers, and filter parameter mapping keys, and generates a unique column identifier (key) for each column configuration metadata object. This unique column identifier is used to ensure the consistency of references to the same column in subsequent processing layers, avoiding column identity confusion caused by changes in internationalization of display titles or duplicate data field identifier names. When generating the unique column identifier, the original frozen object is not directly modified. Instead, the unique column identifier is merged with the original fields by creating a new object, for example, by using the spread operator or the Object.assign() method to generate a standardized column configuration object. The standardized column configuration object can be further frozen using the Object.freeze() method, or at least its references are kept unmodified in subsequent processes, thereby forming a standardized immutable column configuration metadata set. This set serves only as source data for subsequent derivation and rendering, and is not directly modified by any downstream component throughout the entire rendering lifecycle.

[0019] Step 103: Traverse the immutable column configuration metadata set, identify columns containing filter type tags, deduce the mapping relationship between filter interaction components and request parameters based on filter type tags, bind the filter interaction components to the column header of the corresponding column, and initialize the filter value state.

[0020] In this context, the filter interaction component refers to an interactive control displayed in the column header area and capable of receiving user filtering operations, such as a multi-select dropdown selector or a date range selector. The derivation process determines the filter interaction component type based on a preset correspondence between markers and component types; for example, a status filter marker corresponds to a multi-select selector, and a time range filter marker corresponds to a date range selector. Simultaneously, filter option data is retrieved from a preset data source configuration based on the filter type marker, and the filter interaction component is bound to the corresponding column header. The binding method can be to inject the filter interaction component into the column header rendering logic through the filter dropdown attribute in the column definition object, allowing the user to see and operate the filter interaction component after clicking on the column header. In the table mapping method of this embodiment, request parameters refer to all key-value pairs carried in the request body when the table component sends a request to the backend data query interface. These parameters are used to tell the backend the conditions and ranges that the query needs to meet, and typically include: pagination-related parameters, filtering-related parameters, sorting-related parameters, and fixed parameters, such as the currently logged-in user identifier loginName or page identifier pageCode, used for permission and context identification. These parameters collectively constitute the "request parameters," which the backend uses to execute queries and return tabular data. The request parameter mapping relationship refers to the correspondence and conversion rules between the "output values ​​of the filtering component" and the "specific key-value pairs in the backend request parameters." Specifically, it describes how to convert user selections in the filtering interaction component into request parameters that conform to the backend interface conventions. In this solution, this mapping rule is not handwritten by the developers but is derived from the filtersKey (filter parameter mapping key) and filter type tag pre-declared in the column configuration metadata. Generated based on the filter parameter mapping key, the filter parameter mapping key serves as the key name in the final request parameters. The output value of the filtering interaction component is converted according to preset rules and corresponds to this key name. For example, the output array of a multi-select component can be directly used as parameter values, and the output of a date range component can be formatted as an object containing start and end attributes. After identification and derivation, the filter value state is initialized. The filter value state can be a state container with the filter parameter mapping key as the key and the user-selected value as the value; initially, each key corresponds to an empty value or a default value. This filter value state is used for subsequent request parameter assembly and is updated when the user interacts with the filtering interaction component. It should be noted that the filter type marker in this embodiment has been pre-declared, and the filter component type, data source and parameter mapping do not need to be manually bound by the developer.

[0021] Step 104: Obtain the current pagination status and current sorting status maintained by the table component, assemble the request parameters based on the current pagination status, filter value status, and current sorting status, and call the data interface to obtain the table data list.

[0022] Specifically, after deriving the filtering capabilities, the current pagination state and current sorting state maintained by the table component are obtained. The table component typically maintains its own pagination state, including the current page number and page size, and its sorting state, including the sorting field and sorting direction. These states can be displayed to the execution system executing this method through state promotion, callback functions, or a global state container. Subsequently, request parameters are assembled based on the current pagination state, filter value state, and current sorting state. During assembly, the values ​​in the filter value state are converted into key-value pairs in the request parameters according to their corresponding filter parameter mapping keys; the pagination state is mapped according to preset page number and page size parameter keys; and the sorting state is formatted as a string concatenated with field names and sorting direction, or a sorting parameter format agreed upon by the backend. The assembled request parameter body calls the data interface to obtain the table data list. The table data list returned by the data interface typically includes data field values ​​corresponding to data field identifiers, as well as pagination information such as the total number of records. The obtained table data list can be formatted as needed, and a unique row identifier is generated for each row of data for the table component to perform row rendering and state management.

[0023] Step 105: Based on the immutable column configuration metadata set and the filter interaction component already bound to the column header, generate the final column definition set, and pass the final column definition set, table data list and current pagination status to the table component for rendering.

[0024] Specifically, a final column definition set is generated based on an immutable column configuration metadata set and filter interaction components already bound to column headers. When generating the final column definition set, the original metadata objects in the immutable column configuration metadata set are not modified; instead, new column definition objects are created according to rendering requirements. For example, fields from the original metadata object can be copied to the new object using the spread operator, and the bound filter interaction components can be written as additional attributes to the new object, resulting in a final column definition object that contains both the original column configuration information and filter interaction capabilities. Since the references to the original metadata objects remain unchanged during generation, when changes in filter value status or pagination status trigger a re-render, the virtual DOM difference comparison algorithm of the declarative rendering framework can quickly determine that the relevant nodes of the column definition have not changed through reference equality, thus skipping deep comparisons and reducing rendering overhead. The final column definition set, the table data list, and the current pagination status are then passed to the table component for rendering. The table component renders the data list as table rows based on the display titles, data field identifiers, and custom rendering functions in the column definition set, and renders the pagination controls according to the pagination status. User actions in the filtering interaction component will update the state of the filter value, thereby triggering the reassembly of request parameters and data retrieval. The reference stability of the immutable column configuration metadata set ensures that the column definition part will not be accidentally modified or recalculated throughout the rendering pipeline.

[0025] Compared with related technologies, this embodiment achieves the immutability guarantee of column configuration metadata and the declarative deduction of filtering capabilities by defining and freezing column configuration metadata, parsing and generating a standardized immutable set, deriving filtering capabilities based on filtering tags, assembling multi-source state request parameters, and generating and rendering the final column definition set. Since the immutable metadata reference remains stable throughout the rendering lifecycle, unnecessary deep comparisons during the virtual DOM comparison process are reduced. Simultaneously, the filtering type tags eliminate the inconsistency risks associated with manually binding component types, data sources, and parameter mappings, thereby improving the efficiency of table rendering and the maintainability of the configuration.

[0026] The second embodiment of the present invention relates to a table rendering method based on immutable column configuration metadata. This embodiment is a supplement to the foregoing embodiments and specifically includes the following contents.

[0027] In one example, the column configuration metadata object also includes: resource type identifier; filter type tags include: status filter tag, cloud region filter tag, and time range filter tag.

[0028] The column configuration metadata object also includes a resource type identifier. The resource type identifier declares the type of business resource the current table supports. For example, an Elastic Compute Service instance can be identified as "ecs," and a Relational Database Service instance can be identified as "rds." The data source for filtering options for the same field may differ under different resource types. Filter type markers specifically include a status filter marker (isStatusFilter), a cloud region filter marker (isCloudRegionFilter), and a time range filter marker (isTimeRangeFilter). The status filter marker indicates that the column needs to be injected with instance status enumeration filtering capabilities; the cloud region filter marker indicates that the column needs to be injected with cloud region list filtering capabilities; and the time range filter marker indicates that the column needs to be injected with date range filtering capabilities.

[0029] Based on this, the filter interaction component based on filter type tag in step 103 includes: component type inference and option data source route inference; Component type inference is used to map status filter tags and cloud region filter tags to multi-select dropdown interactive components, and time range filter tags to date range selection interactive components; The option for data source routing inference is used to automatically route data source interfaces based on a combination of filter type flags and resource type identifiers; wherein, the same filter type flag is routed to different data source interfaces under different resource type identifiers.

[0030] Component type inference refers to directly mapping filter type tags to corresponding interactive component types. Specifically, state filter tags and cloud region filter tags are mapped to multi-select dropdown interactive components, such as the Select multi-select component in the Ant Design component library; time range filter tags are mapped to date range selection interactive components, such as the DatePicker.RangePicker range selection component in the Ant Design component library. This mapping relationship can be predefined in a configuration table or mapping function. When a column is found to contain a state filter tag, it is determined that a multi-select dropdown interactive component needs to be rendered for that column, eliminating the need for developers to specify the component type separately for each column.

[0031] Option data source routing inference refers to the automatic routing of data source interfaces based on the combination of filter type tags and resource type identifiers. The same filter type tag will route to different data source interfaces under different resource type identifiers. For example, when the resource type identifier is "ecs" and the filter type tag is a status filter tag, it automatically routes to the ECS instance status enumeration interface; when the resource type identifier is "rds" and the filter type tag is a status filter tag, it automatically routes to the RDS instance status enumeration interface. This routing process is automatically completed by the system based on the tag combination, eliminating the need for developers to manually specify the interface address in the column configuration metadata. Compared to the existing approach of configuring the data source interface separately for each column, this combined routing mechanism eliminates the implicit contract of manually modifying the interface address due to resource type switching, ensuring correct matching between the data source and the resource type context. In actual implementation, a mapping table can be maintained with filter type tags and resource type identifiers as keys and data source interface configurations as values. During parsing, the corresponding interface address is obtained by looking up the table, and then the interface is asynchronously called to retrieve option data. The retrieved option data can be injected into the option list of a multi-select dropdown interactive component for user selection. For time range filtering tags, it is usually not necessary to asynchronously fetch the data source; instead, the date range selection component's own date panel can be used directly.

[0032] The request parameter mapping relationship derived based on filter type tags includes: The filter parameter mapping key in the column configuration metadata object is used as the parameter key name in the backend request corresponding to the filter value in the filter value status.

[0033] Specifically, when deriving request parameter mapping relationships based on filter type tags, the process includes: using the filter parameter mapping key (filtersKey) in the column configuration metadata object as the parameter key name for the corresponding filter value in the filter value status in the backend request. That is, when a user selects multiple status values ​​in a multi-select dropdown interactive component, the system uses the pre-declared filtersKey of that column as the key name for the request parameter, converting the user's selected values ​​and using them as the values ​​corresponding to that key name. For example, if a status filter column declares filtersKey as "status", the final request parameters will contain an array of values ​​with "status" as the key name. For time range filter columns, the time range value corresponding to its filtersKey can be formatted as an object or array containing start and end times, serving as the value corresponding to that key name. Furthermore, the request parameter mapping relationship can also include preset output value conversion rules, such as splitting multi-select values ​​into arrays, formatting range values ​​as [start, end] objects, and handling null values.

[0034] In this embodiment, the filter parameter mapping key in the column configuration metadata object becomes the only mapping source that needs to be considered when assembling request parameters, as described above. During the request parameter assembly phase, the system iterates through each key-value pair in the filter value state, directly using the key name as the request parameter key name, and converting the value according to the filter type marker of the corresponding column before using it as the parameter value. Finally, it merges with other pagination parameters and sorting parameters to form a complete request parameter body. This process is closely related to the filter type marker and resource type identifier in the column configuration metadata, forming a complete derivation chain from marker to component type, data source interface, and then to request parameters. Because the derivation chain is entirely driven by explicit declarations in the metadata, it avoids the problem of misalignment between filter state and request parameters caused by inconsistent manual binding by developers, improving the reliability and maintainability of the table filtering function.

[0035] During the table filtering process, there may be semantic dependencies between different filtering dimensions. Therefore, in another example, when a change is detected in the filter value state corresponding to the state filter flag, such as... Figure 2 As shown, the method in this embodiment further includes the following steps 201-202: Step 201: If there is a preset linkage relationship between the column corresponding to the status filter mark and the column corresponding to the cloud area filter mark, then clear the value in the filter value status corresponding to the cloud area filter mark.

[0036] Specifically, preset linkage relationships can be predefined in the column configuration metadata or maintained uniformly by the system configuration center. A preset linkage relationship refers to a declaration in the column configuration metadata or system configuration that there is a dependency between one filter column and another. When the value of the upstream filter column changes, the option data and current selection value of the downstream filter column need to be recalculated or reset. In actual implementation, this relationship can be maintained by adding a linkage identifier field to the column configuration metadata object or by using a mapping table with the filter parameter mapping key as the key and the linkage target column as the value. This embodiment does not impose specific limitations on this.

[0037] When a change is detected in the filter value status corresponding to the status filter marker, the system first determines whether there is a preset linkage relationship between the column corresponding to the status filter marker and the column corresponding to the cloud region filter marker. The filter value status uses the filter parameter mapping key as the key; therefore, the specific implementation of the detection can be to listen to the filter value status, obtain the specific key name that has changed after the status is updated, and then look up whether a corresponding linkage configuration exists based on that key name. Listening can be implemented through side-effect functions in the status management mechanism, such as using React's `useEffect` hook to listen for changes in the filter value status and execute the linkage judgment logic when a change occurs. If no preset linkage relationship is detected, no additional processing is performed; only the request parameter assembly and data retrieval are triggered according to the normal process. If a preset linkage relationship is detected, the system first clears the value corresponding to the cloud region filter marker in the filter value status. Specifically, when the upstream status filter conditions change, the previously selected cloud region filter value may no longer meet the new semantic constraints. If it is not cleared, the invalid cloud region filter value will continue to exist in the request parameters, causing the backend query results to be inconsistent with the user's expectations. The clearing operation can be implemented by calling a state update function to set the value corresponding to the cloud region filter mapping key to an empty value or a default value, such as an empty array, an empty string, or null. The specific implementation depends on the output format convention of the filter component, and this embodiment does not impose any specific restrictions. After clearing, the user needs to reselect from the updated cloud region options. This process ensures that the cloud region filter conditions in subsequent request parameters necessarily come from the currently valid set of options.

[0038] Step 202: Using the value corresponding to the status filter mark in the changed filter value status as a parameter, call the data source interface of the column corresponding to the cloud area filter mark again to update the filter option data of that column.

[0039] Specifically, after the clear operation is executed, the data source interface for the column corresponding to the cloud region filter flag is called again, using the value corresponding to the status filter flag in the changed filter value status as a parameter, to update the filter option data for that column. This operation ensures the matching relationship between the filter option data and the current upstream filter value at the data source level. When the data source interface is called again, the system passes the changed status filter value as part of the request parameter to the data source interface. After receiving this parameter, the data source interface only returns a list of cloud regions that match the selected status, instead of returning the full list of cloud regions. The core of this step is that the acquisition of filter option data is no longer a static loading without context, but a stateful request that is dynamically adjusted according to the upstream filter status. For example, on the Elastic Compute Service instance list page, when the user selects "Running" and "Stopped" instance statuses, the system uses these two status values ​​as request parameters to re-request the cloud region data source interface, and the interface returns a list of cloud regions that contain both of these statuses; however, the cloud region option list that was previously loaded for this column may contain cloud regions that only have instances in other statuses, so they must be replaced. If the option data source interface itself does not support filtering by status, option filtering can be completed locally on the front end through a preset linked data mapping. This involves performing an intersection operation between the full list of cloud regions and the available cloud region mapping table under the selected status to obtain the updated option data, and using the matching result as the updated filtered option data. In the implementation of interface re-call, a loading state can be maintained to avoid duplicate requests. For example, new trigger requests can be temporarily stored while the data source request is in progress and processed uniformly after the current request is completed, or expired responses can be discarded based on the request sequence number.

[0040] After clearing and updating the option data, the value corresponding to the cloud region filter key in the filter value status is empty, and the option list of the cloud region filter interaction component is the re-acquired data. This process does not change the immutable column configuration metadata set itself, but only updates the filter value status and the filter option data source status, thus not disrupting the stability of the metadata references established in previous steps. The subsequent request parameter assembly stage will read the updated filter value status. When the cloud region filter value is empty, the corresponding request parameters will not carry the cloud region filter condition, or, according to the backend interface convention, an empty value will be passed to indicate no filtering, thereby ensuring that the request parameters are consistent with the currently visible filter interaction interface status.

[0041] This embodiment ensures that the interdependent filter dimensions in the table remain consistent throughout the user's operation by declaring preset linkage relationships, detecting state changes, clearing downstream filter values, and re-calling the data source based on upstream filter values. This avoids invalid requests and erroneous query results caused by the semantic invalidation of filter values.

[0042] The third embodiment of the present invention relates to a table rendering method based on immutable column configuration metadata. This embodiment is a supplement to the foregoing embodiments. This embodiment further introduces column management interaction capability into the table rendering method. Column management interaction refers to the function that allows users to choose which columns to display and which columns to hide.

[0043] In one example, such as Figure 3 As shown, the method in this embodiment further includes the following steps: Step 301: Generate tree-structured data based on the immutable column configuration metadata set, and inject the column management interactive panel into the column header.

[0044] Specifically, a tree-structured data (treeData) is first generated based on the immutable column configuration metadata set. This tree-structured data is used to display a list of selectable columns in the column management interactive panel. Each tree node corresponds to a column configuration metadata object. The node key can be a unique column identifier, a data field identifier, or a display title, and the node title is the display title of that column. For system-essential fixed columns, such as "Instance ID" and "Operation," the corresponding tree nodes can be marked as non-interactive, for example, by setting the disabled property to true, preventing users from unchecking these columns in the panel. The process of generating the tree-structured data does not modify the original immutable column configuration metadata set; instead, it creates new tree node objects, thus maintaining the metadata references. The column management interactive panel is then injected into the column header rendering logic of the basic table component. This injection can be achieved by attaching a filter dropdown property (filterDropdown) to the column definition object of the last data column. The value of this property is the component instance that renders the column management interactive panel. When the user clicks the interactive entry in the column header, the column management interactive panel expands and displays. The panel contains a list of selectable tree columns rendered based on tree structure data and temporary selection states, as well as a save button.

[0045] Step 302: Maintain the temporary selection state and the confirmed state in the column management interaction panel. The temporary selection state is used to record the user's real-time selection operation in the column management interaction panel, and the confirmed state is used to record the column display state after the last save.

[0046] Specifically, the column management interaction panel maintains two sets of states: temporary selection states (tempCheckedKeys) and confirmed states (checkedKeys). The temporary selection state records the user's real-time selections in the panel, reflecting the intermediate state the user is currently adjusting but has not yet saved. The confirmed state records the column display state after the last save, determining which columns the table actually renders. Both states can have the same initial value, derived from the currently effective column display configuration. Each time the user selects or deselects a column in the tree list, the system only updates the temporary selection state, not synchronizing the changes to the confirmed state; therefore, the actual columns displayed in the table remain unchanged. Each intermediate user action only alters the visual feedback within the panel, without triggering re-rendering of the table components based on the column definition set, nor triggering re-rendering of other parallel components subscribed to column configuration information, thus avoiding unnecessary data requests and rendering overhead.

[0047] Step 303: When a user selects or deselects a column in the column management interaction panel, only the temporary selection status is updated; when the user triggers a save operation and saves successfully, the temporary selection status is synchronized to the confirmed status, and the column definition set is filtered according to the confirmed status to generate the final column definition set.

[0048] Specifically, when a user clicks the save button in the column management interaction panel, triggering a save operation, the system executes the persistence process for column display preferences. The specific implementation of the persistence process depends on the persistence mode flag (saveToBackend). When the persistence mode flag is true, the system calls the backend column preference save interface, sending the list of visible column flags corresponding to the current page flag and the temporary selection state to the backend storage; the backend performs update or insert operations according to the user flag and page flag dimensions, and repeated saves only overwrite the original records without creating multiple records. When the persistence mode flag is false or the network request fails, the system falls back to writing the list of visible column flags to the browser's local storage. Regardless of the persistence method used, the system only synchronizes the temporary selection state to the confirmed state after the save operation is successful. The synchronization action triggers a controlled change to the confirmed state, which in turn drives the recalculation of the subsequent column definition set and the table rendering update. If the save operation fails, the temporary selection state is not synchronized to the confirmed state, the confirmed state remains unchanged, the table view does not change, the user interface state remains stable, and an error message can be output for the user to know.

[0049] After successful saving and synchronization from the temporary selection state to the confirmed state, the system filters the column definition set based on the confirmed state to generate the final column definition set. The filtering operation uses a non-intrusive array transformation method, such as using the `Array.prototype.filter` method to create a new array instance based on the visible column identifiers in the confirmed state. For each retained column object, a new column definition object is created using the spread operator, and a column management interaction entry is attached. During this process, the original immutable column configuration metadata object and its references are not modified; only the new filtered array and new objects are created. Because the original immutable metadata references remain stable, a new final column definition set reference is generated and a controlled re-render is triggered only when the confirmed state changes. Any changes in the temporary selection state do not affect the references to the final column definition set, and therefore do not trigger rendering difference calculations based on the column definition set.

[0050] During the generation of the final column definition set, it is also necessary to protect fixed columns. Fixed columns are those that the system requires to be always visible, such as row selection columns and operation columns. In tree-structured data, the nodes corresponding to fixed columns are marked as non-interactive, so users cannot deselect them through checkboxes in the panel. When filtering the column definition set based on the confirmed status, the system can further perform deduplication and merging logic, merging the column identifier set of fixed columns with the set of visible column identifiers in the confirmed status, ensuring that fixed columns are always included in the filtered final column definition set. Even if fixed column identifiers are missing in the backend storage or local storage due to historical data anomalies, the frontend deduplication and merging can correct this anomaly and guarantee the mandatory display of fixed columns.

[0051] In another example, the save operation in the above embodiment includes: selecting a storage route based on a persistence mode identifier, which indicates whether to save the column preferences to the backend; Based on this, the method in this embodiment further includes: When the persistence mode flag is true, a save request is sent to the backend column preference saving interface. The save request includes a page flag and a list of visible column flags. The page flag is used to identify the current table page, and the list of visible column flags is a set of unique column flags of the columns currently selected by the user. When the persistence mode is marked as false or there is a network error, the list of visible column identifiers is written to the browser's local storage. When loading column preferences, the list of visible column identifiers is read from the corresponding storage and merged with the fixed column set as the initial confirmed state and the initial temporary selection state.

[0052] Specifically, the save operation in the column management interactive panel involves the selection of persistence mode and storage routing. The persistence mode identifier (saveToBackend) indicates whether to save column preferences to the backend. This identifier can be passed in by the business module during table component initialization, or it can be maintained centrally by the system configuration center.

[0053] When the persistence mode flag is true, the system sends a save request to the backend column preference saving interface. The save request includes a page identifier (pageCode) and a list of visible column identifiers (visibleColumns). The page identifier uniquely identifies the current table page; for example, the Elastic Compute Service instance list page can be identified as "ECSInstanceList," and the relational database instance list page can be identified as "RDSInstanceList." Column preferences for different pages are stored independently and do not interfere with each other. The list of visible column identifiers is a collection of unique column identifiers for the columns currently selected by the user. This collection originates from the temporary selection state and is mandatory to include fixed column identifiers. In actual implementation, the backend interface can be defined as POST / workorder / columnConfig / save, with the request body in JSON format. After receiving the save request, the backend parses the currently logged-in user identifier (loginName) from the gateway information, without requiring additional transmission from the frontend. The backend performs update or insert operations using the page identifier and user identifier as a composite key; if a corresponding record already exists, it is updated; otherwise, it is created. Saving the same configuration repeatedly will only overwrite the original record, preventing the creation of multiple records and ensuring that each user has only one column preference configuration per page.

[0054] The backend only stores the list of visible column identifiers, not any field semantic information. Field semantic information refers to information describing the meaning and display behavior of columns, such as column name, column width, rendering method, and filter component type. This semantic information is maintained by the frontend's immutable column configuration metadata set. The backend only acts as a transparent storage medium for the visible column identifier list, without interpreting the specific meaning of each identifier. When a new display field needs to be added, developers only need to add a new metadata object to the frontend's column configuration metadata array; the backend interface and database structure do not need to be modified. This separation of responsibilities between the frontend and backend eliminates the problem of bidirectional synchronous publishing when adding a field. When modifying column display preferences, the frontend is responsible for converting the temporary selection state into a list of visible column identifiers and sending it to the backend. When restoring column display preferences, the frontend retrieves the list of visible column identifiers from the backend and then maps the identifiers to specific column configuration metadata based on the complete set of field semantics maintained by the frontend, determining which columns to display and which to hide.

[0055] When the persistence mode is false or a network error occurs, the system writes the list of visible column identifiers to the browser's local storage (localStorage). Browser local storage is a key-value pair-based persistent storage mechanism provided by the browser. Data is stored in the user's current browser and is not synchronized across devices with the account. When a backend save request fails, it degrades to local storage, ensuring that the user's column preferences in the current browser are not lost due to network errors. In practice, the page identifier can be used as the key for local storage, and the serialized result of the visible column identifier list can be used as the key-value pair. For example, the array can be converted to a string using the `JSON.stringify` method and then written to localStorage. When reading, the `JSON.parse` method is used to restore the array from the string. Local storage mode also does not store field semantic information, only the identifier list. When the persistence mode is false, the system directly uses local storage without initiating a network request; when the persistence mode is true but a network error occurs, the system switches to local storage after intercepting the error, ensuring fault tolerance in the save operation.

[0056] When loading column preferences, the system reads a list of visible column identifiers from the corresponding storage. The corresponding storage refers to the storage medium where the actual write operation is stored under the current persistence mode identifier. When the persistence mode identifier is true, it reads from the backend by calling the POST / workorder / columnConfig / get interface, with the request body containing the page identifier. The backend returns an array of visible column identifiers. When the persistence mode identifier is false or there is a network error, it reads from the browser's local storage. The read list of visible column identifiers is merged with the fixed column set to serve as the initial confirmed state and the initial temporary selection state. The fixed column set contains the identifiers of columns that the system requires to be always visible.

[0057] In one example, the fixed column set contains an instance ID column and an operation column; In the column management interactive panel, the tree node corresponding to the fixed column set is marked as disabled; when generating the list of visible column identifiers, the fixed column set is always included.

[0058] The merging operation can be implemented using a set-based deduplication merging mechanism. For example, a Set data structure can be used to merge the visible column identifier list with the identifiers in the fixed column set, and then expand them into a new array. The merged result serves as the initial value for both the initial confirmed state and the initial temporary selection state, ensuring consistency between the two sets of states upon initial loading. If the visible column identifier list read from storage is an empty array, it means that the user has not yet saved column preference configurations for this page. In this case, the system will process it according to the front-end default configuration, i.e., all non-hidden columns will be displayed, and the merged result with the fixed column set will also serve as the initial state.

[0059] During initial loading, the operation of reading the list of visible column identifiers from storage and merging it with the fixed column set should be coordinated in timing with the derivation of filtering capabilities and the initial data request. The initial restoration of column management state should be completed before the first rendering. When column preferences originate from backend storage, due to network latency, it is necessary to wait for the interface to return before confirming the initial state. If the table has already completed its initial data request and rendering during this waiting period, subsequent state updates after confirmation will trigger an additional re-render, causing visual flickering and performance waste. Therefore, the column preference loading state can be incorporated into a unified readiness gating system, jointly controlling the triggering timing of the first data request with the filter option loading state, ensuring that both the column display state and the filter option state are ready before the first data request is issued.

[0060] The fourth embodiment of the present invention relates to a table rendering method based on immutable column configuration metadata. This embodiment is a supplement and refinement to the foregoing embodiments, and specifically includes the following contents.

[0061] like Figure 4 As shown, step 104, which assembles the request parameters based on the current pagination status, filter value status, and current sorting status, includes the following steps: Step 401: Convert the filter value in the filter value status according to the corresponding filter parameter mapping key to obtain the filter request parameter; The filter request parameters include: the start value object and end value object obtained by formatting the output value of the multi-select dropdown interactive component and the output value of the date range selection interactive component.

[0062] Specifically, when assembling filter request parameters, the system iterates through each item in the filter value state. The filter value state uses the filter parameter mapping key as the key and the value selected or entered by the user through the filter interaction component as the value. For each key-value pair, the system determines the value format conversion rules based on the filter type flag declared in the configuration metadata corresponding to that key. When the filter type flag is a status filter flag or a cloud region filter flag, the corresponding filter interaction component is a multi-select dropdown interaction component, whose output value is usually an array, where each element is an item selected by the user. The system can directly use this array as the request parameter value, but in some backend interface conventions, it may be necessary to further split or encode the values ​​in the array. Splitting refers to the system converting the array into the backend-defined format when the backend interface requires the multi-select values ​​to be passed as comma-separated strings or repeated key-value pairs. When the filter type flag is a time range filter flag, the corresponding filter interaction component is a date range selection interaction component, whose output value is usually an array or object containing start and end times, such as [startDate, endDate]. The system formats this output value into a start value object and an end value object, which serve as the start and end parameter values ​​in the request parameters for that filtering dimension, respectively. The specific format of the start and end value objects is determined by preset rules and can be a timestamp, a date string, or a date format object conforming to backend conventions. Regardless of the format, the conversion rules are automatically determined based on the filter type marker declared in the column configuration metadata, eliminating the need for developers to write additional format conversion code during the request parameter assembly stage. The filtered request parameters ultimately use the filter parameter mapping key as the key name and the converted value as the value, forming the filtered part of the request parameters.

[0063] Step 402: Map the current pagination status according to the preset pagination parameter key name to obtain the pagination request parameters.

[0064] Specifically, when assembling pagination request parameters, the system reads the current pagination state maintained by the table component. The current pagination state typically includes two dimensions: the current page number and the page size. The system maps these parameters according to preset pagination parameter keys. For example, the request parameter key corresponding to the current page number is designated as the page number parameter key (pagenumberKey), and the request parameter key corresponding to the page size is designated as the page size parameter key (pagesizeKey). These preset pagination parameter keys can be passed in by the business module through a configuration object during table component initialization, or they can be maintained centrally in the system configuration center. The mapping process only involves key name replacement and does not involve further value processing; that is, the value of the current page number is assigned to the page number parameter key, and the value of the page size is assigned to the page size parameter key to obtain the pagination request parameters. Different business pages may use different pagination parameter key names, but the mapping logic is consistent.

[0065] Step 403: Format the current sorting status as a string concatenated with the field name and sorting direction to obtain the sorting request parameters.

[0066] Specifically, when assembling the sort request parameters, the system reads the current sort status maintained by the table component. The current sort status typically includes two dimensions: the sort field and the sort direction. The sort field identifies which column the user wants to sort by, usually corresponding to the data field identifier or unique column identifier of that column. The sort direction indicates ascending or descending order. The system formats the sort status into a string concatenated with the field name and the sort direction, resulting in the sort request parameters. For example, when the sort field is "createTime" and the sort direction is descending, the formatted result is "createTime desc". The specific concatenation format can be determined by preset rules, such as using spaces or commas to separate the field name and direction, or adding a direction prefix before the field name. The formatted sort string serves as the sorting part in the request parameters, with the key name determined by the backend interface convention. When the sort status is empty, the sort request parameters can be omitted or an empty value can be passed, indicating that no sorting is specified.

[0067] Step 404: Combine the filter request parameters, pagination request parameters, sorting request parameters, and preset fixed parameters to obtain the complete request parameter body corresponding to the request parameters.

[0068] Specifically, after assembling the filter request parameters, pagination request parameters, and sorting request parameters, the system merges these three with preset fixed parameters to obtain the complete request parameter body corresponding to the request parameters. Preset fixed parameters refer to parameters that must be carried in every data request and do not change with the interaction state, such as login user identifier, resource type identifier, and page identifier. Fixed parameters can originate from the system context, authentication information, or the initialization configuration of the business module. The merging operation can combine the various parameters into a single request parameter object through object expansion or item-by-item assignment. In actual implementation, the object expansion operator can be used to sequentially expand and merge the fixed parameter object, filter request parameter object, pagination request parameter object, and sorting request parameter object. If a later expanded part has the same key name as an earlier expanded part, the value of the earlier expanded part is overwritten, thus ensuring that dynamic state parameters take precedence over the default values ​​of fixed parameters. After merging, the system calls a unified data request interface to send the request address and the complete request parameter body to the backend list query interface.

[0069] In the implementation of request parameter assembly triggering, the system simultaneously monitors changes in pagination status, filter value status, and sorting status through a state listening mechanism. When any of these changes, the system executes the aforementioned request parameter assembly process. For the filter value status, since this status uses the filter parameter mapping key as the key, the system can accurately identify which filter dimension the change originated from, thus retaining the current values ​​of the remaining unchanged filter dimensions in the new request parameters and only updating the values ​​of the changed dimensions. For the pagination status, reassembly is triggered when the user flips through pages or modifies the size of each page. For the sorting status, clicking the sortable list header triggers a change in sorting direction or sorting field, thereby triggering reassembly. Because all parameters are generated within the same assembly logic, the request parameters received by the backend always contain complete filtering, pagination, and sorting conditions, eliminating the possibility of missing request conditions due to a missed assembly of a certain type of parameter in a particular interaction path.

[0070] After assembly, the system calls the data interface and waits for a response. The backend queries the data based on the filtering conditions, pagination range, and sorting rules in the complete request parameter body, returning a table data list and the total number of records. The system formats the returned data and generates a unique row identifier for each row if necessary. The updated table data list and total number of records are then passed to the table component for rendering. Throughout this process, the reference to the column configuration metadata itself remains stable. Request parameter assembly only involves reading and transforming state values ​​and does not modify the column configuration metadata object. Therefore, the re-rendering of the column definition part can still be quickly skipped by the virtual DOM difference comparison algorithm.

[0071] After the derivation and injection of filtering capabilities are completed, the filtering interaction components need to obtain their respective option data in order to provide the user with selectable filter values. In another example, the method of this embodiment further includes: The method also includes: Before retrieving the list of table data, initiate asynchronous requests to the data source for all columns containing filter type tags. Once all requests are completed, update the filter option status and set the filter ready flag at once. The filter ready flag is used to indicate whether all filter option data has been loaded. Once the filter-ready flag is true, the first table data request can be initiated.

[0072] Specifically, before obtaining the list of table data, the unified control unit initiates asynchronous requests to the data source for all columns containing filter type markers. In this embodiment, an asynchronous request means that after the request is initiated, it does not block subsequent code execution, but rather notifies the caller of the processing result through a callback function or state update mechanism when the response is returned. In front-end rendering frameworks, asynchronous requests are typically initiated during the component mounting phase through side effects, such as using React's `useEffect` hook and passing in an empty dependency array, indicating that the side effect is executed only once during component mounting. Unified initiation means that during a single side effect execution, all columns containing filter type markers in the immutable column configuration metadata set are traversed, and asynchronous requests are initiated sequentially or in parallel for each column based on the previously derived data source interface address. Parallel initiation can be achieved using the `Promise.all` method. A Promise is an object representing the eventual completion or failure of an asynchronous operation. `Promise.all` receives an array of multiple Promises and returns a new Promise. This new Promise enters the completed state when all input Promises complete successfully and enters the failed state when any input Promise fails. The Promise.all method can be used to unify the completion times of all data source requests for filtering options into a single, waitable aggregate result.

[0073] After all asynchronous requests are completed, the system updates the filter option state all at once. The filter option state is a container with filter parameter mapping keys or filter column identifiers as keys and a list of option data as values. The update operation is completed in a single state commit, rather than updating each column individually. The significance of a one-time update is to ensure the atomicity of the filter option state update, avoiding intermediate states where some columns of options have been updated while others have not, being rendered to the interface. In the specific implementation, the system extracts the option data from the respective responses column by column in the aggregated result returned by `Promise.all`, assembles the option data into a complete new state object according to the corresponding key names, and then calls the state update function to replace the entire filter option state with this new state object. Because the state update function is called only once, declarative rendering frameworks like React can see that all column option data is ready in the next render, without capturing intermediate rendering results where some column options are missing.

[0074] While updating the filter option status all at once, the system sets a filter ready flag. The filter ready flag indicates whether all filter option data has been loaded. This flag can be a Boolean state variable, initially false. It is set to true only after all data source requests for all filter columns have successfully completed and the filter option status has been updated as a whole. If any data source request for a filter column fails, the system can decide whether to set the filter ready flag to true based on a preset strategy. One strategy is to keep the flag true even if some requests fail, but the corresponding column's option data will be an empty array, and a prompt will be displayed on the interface; another strategy is to keep the filter ready flag false if any request fails and trigger a retry mechanism. Regardless of the strategy used, the core function of the filter ready flag is to provide a clear timing gate for the logic of initiating the first table data request, enabling the request initiator to declaratively determine whether the conditions for initiating a request are met.

[0075] After the filter-ready flag is true, the system allows the first table data request to be initiated. The logic for initiating the first table data request listens for changes in the filter-ready flag. When the flag changes from false to true, the request parameter assembly and data retrieval process is executed. In the implementation, conditional triggering can be achieved by relying on the filter-ready flag in the side-effect function. Specifically, during the initial rendering, the side-effect function related to the table data request is called, but the function body first checks whether the filter-ready flag is true. If it is false, the request logic is skipped and the function returns directly. When the filter-ready flag is set to true due to the completion of all asynchronous requests, the state update triggers the component to re-render, and the side-effect function is executed again. This time, the check passes, and the request parameter assembly and data retrieval process continues. In this way, the timing ensures that the first table data request always occurs after all filter option data is ready.

[0076] It's important to note that column preference loading and filter option loading also require timing coordination. The completion of column preference loading directly affects which columns are displayed in the final column definition set, and these columns may include filter columns. If column preference loading is incomplete, some filter columns that should be displayed may not be included in the rendering, and their option data source requests will not be covered in the initial unified initiation phase; or a column that should be hidden may still have its option data source request initiated, resulting in an invalid request. Therefore, in practical implementation, the column preference loading status and filter option loading status can be incorporated into a unified readiness gating system. Specifically, the system maintains a comprehensive readiness flag, which is set to true when column preference loading is complete and all filter readiness flags are true. The initial table data request is initiated based on this comprehensive readiness flag.

[0077] By uniformly initiating data source requests for filter options, waiting for all requests to complete before updating the filter option status and setting a filter ready flag, and then using this flag as the gating condition for the initial table data request, this invention eliminates the timing race between the asynchronous loading of filter option data and the initial table data request. When the table is first rendered, all option data for visible filter columns has already been loaded. The filter component can display the complete set of options before the user's first interaction, avoiding inconsistencies in the interface state and ambiguities in user operations caused by delayed option data.

[0078] The following example illustrates a specific UI rendering process, showcasing the interface effects of column settings and related filtering interactions. The table area in the image displays a "No Data" status, which is the normal display state when the monitoring platform has no monitoring data reported within the corresponding time period and does not affect the demonstration of the technical solution of this invention.

[0079] like Figure 5 The image shows a rendering example of the overall interface of the ECS instance list page, including table data display (instance ID, instance name, instance type, IP address, status, cloud region, etc.), pagination control, sorting interaction, filtering interaction, and column settings buttons in the upper right corner.

[0080] like Figure 6 As shown, Figure 6 This demonstrates a floating window interface for column settings. Clicking the column settings button opens a floating window containing a selectable tree-like list of columns. Fixed columns such as "Instance ID" and "Operation" are grayed out and cannot be unchecked, while the remaining columns are freely selectable. A "Save Settings" button is provided at the bottom. After the user saves the settings, the system displays a "Settings saved!" message, and the table is re-rendered based on the user-defined visible columns.

[0081] After saving the column settings, the table rendering effect is as follows: Figure 7 As shown, Figure 7 This demonstrates how, after a user saves their column settings, the table is re-rendered based on the user-defined visible columns. Hidden columns (such as IP address and status) are no longer displayed, fixed columns are always retained, and the table width adjusts automatically.

[0082] like Figure 8 As shown, Figure 8 This demonstrates a dropdown filter panel for cloud region filtering, listing all available cloud regions in the form of multiple checkboxes. Users can select one or more regions for filtering, and a data request is triggered in real time after selection.

[0083] like Figure 9 As shown, Figure 9 The table shows a query criteria area above the table, which supports selecting query dimensions (instance name, instance ID, IP address, etc.) from the dropdown menu and entering keywords for fuzzy search.

[0084] like Figure 10 As shown, Figure 10 The drop-down radio panel for the instance type filter column is displayed, providing options such as standalone MySQL, master-slave MySQL, and read-only MySQL. After the user selects, the table data is automatically reloaded.

[0085] The fifth embodiment of the present invention relates to a table rendering system, which includes a table component and a filtering interaction component, such as... Figure 11 As shown, this system also includes: The column configuration metadata definition module 1101 is used to define a column configuration metadata array. Each column configuration metadata object in the column configuration metadata array includes at least a data field identifier, a display title, a filter type flag, and a filter parameter mapping key. A shallow freeze is performed on each column configuration metadata object to form an immutable column configuration metadata array. The table request processing module 1102 is used to parse the immutable column configuration metadata array, traverse and extract key fields and generate unique column identifiers to form a standardized immutable column configuration metadata set. The filter derivation module 1103 is used to traverse the immutable column configuration metadata set, identify columns containing filter type tags, deduce the mapping relationship between filter interaction components and request parameters based on filter type tags, bind the filter interaction components to the column header of the corresponding column, and initialize the filter value state. The data list call module 1104 is used to obtain the current pagination status and current sorting status maintained by the table component, assemble request parameters based on the current pagination status, filter value status and current sorting status, and call the data interface to obtain the table data list; The table component rendering module 1105 is used to generate the final column definition set based on the immutable column configuration metadata set and the filter interaction component already bound to the column header. The final column definition set, the table data list and the current pagination state are then passed to the table component for rendering.

[0086] In some examples, the system of this embodiment also includes: The column management module generates tree-structured data based on an immutable column configuration metadata set and injects it into the column management interactive panel at the column header. The interactive panel maintains temporary selection states and confirmed states. The temporary selection state records the user's real-time selections in the interactive panel, while the confirmed state records the column display state after the last save. When a user selects or deselects a column in the interactive panel, only the temporary selection state is updated. When the user triggers a save operation and saves successfully, the temporary selection state is synchronized to the confirmed state, and the column definition set is filtered based on the confirmed state to generate the final column definition set.

[0087] The column preference saving module sends a save request to the backend column preference saving interface when the persistence mode flag is true. The save request includes a page flag and a list of visible column flags. The page flag identifies the current table page, and the list of visible column flags is a collection of unique column flags for the columns currently selected by the user. When the persistence mode flag is false or there is a network error, the list of visible column flags is written to the browser's local storage. When loading column preferences, the list of visible column flags is read from the corresponding storage and merged with the fixed column set as the initial confirmed state and the initial temporary selection state.

[0088] In summary, it is not difficult to see that this embodiment is a system embodiment corresponding to the aforementioned method embodiments. The implementation details described in the above method embodiments are still applicable and effective in this embodiment, and will not be repeated here.

[0089] The sixth embodiment of the present invention relates to an electronic device, such as... Figure 12 As shown, it includes at least one processor 1202; and a memory 1201 communicatively connected to at least one processor 1202; wherein the memory 1201 stores instructions that can be executed by at least one processor 1202, the instructions being executed by at least one processor 1202 to enable at least one processor 1202 to execute any of the above method embodiments.

[0090] The memory 1201 and processor 1202 are connected via a bus. This bus can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 1202 and memory 1201. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 1202 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 1202.

[0091] Processor 1202 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 1201 can be used to store data used by processor 1202 during operation.

[0092] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements any of the above-described method embodiments.

[0093] Another embodiment of the present invention relates to a computer program product, including computer instructions that, when executed by a processor, implement any of the above-described method embodiments.

[0094] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0095] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0096] While the embodiments disclosed herein are as described above, the foregoing content is merely for the purpose of facilitating understanding of this disclosure and is not intended to limit this disclosure. Any person skilled in the art to which this disclosure pertains may make any modifications and changes in form and detail of the implementation without departing from the spirit and scope of this disclosure; however, the scope of patent protection of this disclosure shall still be determined by the scope defined in the appended claims.

Claims

1. A table rendering method based on immutable column configuration metadata, applied to a table rendering system, the table rendering system including a table component and a filtering interaction component, characterized in that, The method includes: Define a column configuration metadata array. Each column configuration metadata object in the column configuration metadata array includes at least a data field identifier, a display title, a filter type flag, and a filter parameter mapping key. Perform a shallow freeze on each column configuration metadata object to obtain an immutable column configuration metadata array. The immutable column configuration metadata array is parsed, key fields are extracted and unique column identifiers are generated to form a standardized immutable column configuration metadata set. Traverse the immutable column configuration metadata set, identify columns containing the filter type marker, deduce the mapping relationship between the filter interaction component and the request parameter based on the filter type marker, bind the filter interaction component to the column header of the corresponding column, and initialize the filter value state; Obtain the current pagination status and current sorting status maintained by the table component, assemble request parameters based on the current pagination status, the filter value status, and the current sorting status, and call the data interface to obtain the table data list; Based on the immutable column configuration metadata set and the filtering interaction component already bound to the column header, a final column definition set is generated. The final column definition set, the table data list, and the current pagination state are then passed to the table component for rendering.

2. The method according to claim 1, characterized in that, The column configuration metadata object also includes: resource type identifier; the filter type marker includes: status filter marker, cloud region filter marker, and time range filter marker; The filtering interaction component is derived based on the filtering type tag, including: component type derivation and option data source route derivation; The component type derivation is used to map the status filter mark and the cloud region filter mark to a multi-select drop-down interactive component, and the time range filter mark to a date range selection interactive component; The option data source routing derivation is used to automatically route data source interfaces based on the combination of the filter type flag and the resource type identifier; wherein, the same filter type flag is routed to different data source interfaces under different resource type identifiers; The request parameter mapping relationship is derived based on the filter type flag, including: The filter parameter mapping key in the column configuration metadata object is used as the parameter key name in the backend request corresponding to the filter value in the filter value status.

3. The method according to claim 2, characterized in that, When a change is detected in the value corresponding to the state filter flag in the filter value state, the method further includes: If there is a preset linkage relationship between the column corresponding to the status filter mark and the column corresponding to the cloud area filter mark, then clear the value in the filter value status corresponding to the cloud area filter mark; Using the value corresponding to the state filter flag in the changed filter value state as a parameter, the data source interface of the column corresponding to the cloud area filter flag is called again to update the filter option data of that column.

4. The method according to claim 1, characterized in that, The method further includes: Based on the immutable column configuration metadata set, a tree structure data is generated, and the column management interactive panel is injected into the column header; The column management interaction panel maintains a temporary selection state and a confirmed state. The temporary selection state is used to record the user's real-time selection operation in the column management interaction panel, and the confirmed state is used to record the column display state after the last save. When a user selects or deselects a column in the column management interaction panel, only the temporary selection state is updated. When the user triggers a save operation and saves successfully, the temporary selection state is synchronized to the confirmed state, and the column definition set is filtered according to the confirmed state to generate the final column definition set.

5. The method according to claim 4, characterized in that, The save operation includes: selecting a storage route based on a persistence mode identifier, wherein the persistence mode identifier is used to indicate whether to save the column preferences to the backend; The method further includes: When the persistence mode flag is true, a save request is sent to the backend column preference saving interface. The save request includes a page flag and a list of visible column flags. The page flag is used to identify the current table page, and the list of visible column flags is a set of unique column flags of the columns currently selected by the user. When the persistent mode is identified as false or the network is abnormal, the list of visible column identifiers is written to the browser's local storage. When loading column preferences, the list of visible column identifiers is read from the corresponding storage and merged with the fixed column set as the initial confirmed state and the initial temporary selection state.

6. The method according to claim 5, characterized in that, The fixed column set includes an instance ID column and an operation column; In the column management interactive panel, the tree node corresponding to the fixed column set is marked as disabled; when generating the visible column identifier list, the fixed column set is always included.

7. The method according to claim 2, characterized in that, Assembling request parameters based on the current pagination state, the filter value state, and the current sorting state includes: The filter value in the filter value state is formatted according to the corresponding filter parameter mapping key to obtain the filter request parameter; wherein, the filter request parameter includes: a start value object and an end value object obtained by formatting the output value of the multi-select drop-down interactive component and the output value of the date range selection interactive component; The current pagination state is mapped according to the preset pagination parameter key name to obtain the pagination request parameters; The current sorting status is formatted as a string concatenated with the field name and sorting direction to obtain the sorting request parameters; The filtering request parameters, the pagination request parameters, the sorting request parameters, and the preset fixed parameters are combined to obtain the complete request parameter body corresponding to the request parameters.

8. The method according to claim 1, characterized in that, The method further includes: Before retrieving the table data list, asynchronous requests are initiated for all filter option data sources containing the filter type marker. After all requests are completed, the filter option status is updated and a filter ready flag is set. The filter ready flag is used to indicate whether all filter option data has been loaded. Once the filter-ready flag is true, the first table data request can be initiated.

9. A table rendering system, the table rendering system comprising a table component and a filtering interaction component, characterized in that, The system also includes: The column configuration metadata definition module is used to define a column configuration metadata array. Each column configuration metadata object in the column configuration metadata array includes at least a data field identifier, a display title, a filter type marker, and a filter parameter mapping key. A shallow freeze is performed on each column configuration metadata object to form an immutable column configuration metadata array. The table request processing module is used to parse the immutable column configuration metadata array, traverse and extract key fields and generate unique column identifiers to form a standardized immutable column configuration metadata set. The filter derivation module is used to traverse the immutable column configuration metadata set, identify columns containing the filter type marker, deduce the mapping relationship between the filter interaction component and the request parameter based on the filter type marker, bind the filter interaction component to the column header of the corresponding column, and initialize the filter value state. The data list calling module is used to obtain the current pagination status and current sorting status maintained by the table component, assemble request parameters according to the current pagination status, the filter value status and the current sorting status, and call the data interface to obtain the table data list; The table component rendering module is used to generate a final column definition set based on the immutable column configuration metadata set and the filter interaction component that has been bound to the column header, and to pass the final column definition set, the table data list and the current pagination status to the table component for rendering.

10. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the table rendering method based on immutable column configuration metadata as described in any one of claims 1-8.

Images