A chart rendering method, apparatus, device and storage medium

Abstract

The application discloses a chart rendering method and device, equipment and storage medium, relates to the technical field of data rendering, and comprises the following steps: according to the business domain identifier in the page access request, performing data request operation and data reading operation in parallel, generating page rendering marks based on operation results; when the page rendering mark is allowed to render, determining target rendering parameters based on the current data filtering condition, and determining the chart to be rendered based on the chart configuration information in the page access request, when the chart container of the chart to be rendered meets the chart rendering condition, reading the target metadata in the local database based on the business domain identifier; based on the target rendering parameters and the target metadata, a configuration object is constructed to render the corresponding target chart based on the configuration object by using the chart rendering engine. By performing the data request operation and the data reading operation in parallel, the waiting time of page rendering can be shortened, and on-demand rendering of the chart is realized, thereby reducing resource consumption during chart rendering.

Description

Technical Field

[0001] This invention relates to the field of data rendering technology, and in particular to a chart rendering method, apparatus, device, and storage medium. Background Technology

[0002] In enterprise-level financial BI (Business Intelligence) systems, dashboard detail pages are a typical example of highly complex front-end scenarios. They feature a large number of charts of diverse types, with a single page typically containing dozens of chart cards, covering various visualization types such as line charts, pie charts, progress charts, index cards, and tables. Each type has its own rendering logic and data structure. Furthermore, the metadata is massive. Taking financial business as an example, the metadata for a single business domain contains hundreds of indicator definitions and their associated dimensions, with the raw data volume reaching several megabytes, far exceeding the reasonable storage limit of conventional front-end caching solutions.

[0003] In current chart rendering solutions, every time the page loads or the filter conditions change, all charts send independent data requests to the server, resulting in a large amount of redundant network overhead and waiting delays. Furthermore, there is a lack of awareness and utilization of local cache status, which still causes unnecessary rendering blockages even when existing data is cached. In addition, all charts on the page (including those not visible to the user's current viewport) are synchronously instantiated and rendered during page initialization, consuming a large amount of computing resources. This causes the rendering of the first-screen visible charts to be slowed down by the rendering of a large number of invisible charts, resulting in a poor user experience. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a chart rendering method, apparatus, device, and storage medium that, by executing data request operations and data read operations in parallel, can shorten the page rendering waiting time and achieve on-demand chart rendering, thereby reducing resource consumption during chart rendering. The specific solution is as follows: Firstly, this application provides a chart rendering method, including: Parse the page access request to determine the business domain identifier and chart configuration information corresponding to the page access request; Based on the business domain identifier, data request operations and data read operations are executed in parallel, and page rendering marks are generated based on the operation results of the data request operations and the data read operations; the data request operation is used to request corresponding indicator metadata from a preset server based on the business domain identifier, and the data read operation is used to read corresponding cached data from a local database based on the business domain identifier. When the page rendering flag is set to allow rendering, the corresponding target rendering parameters are determined based on the current data filtering conditions; The chart to be rendered is determined based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, the target metadata in the local database is read based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area. Based on the target rendering parameters and the target metadata, a corresponding configuration object is constructed, and the corresponding target chart is rendered using the chart rendering engine based on the configuration object.

[0005] Optionally, generating page rendering tags based on the operation results of the data request operation and the data read operation includes: When the cached data in the local database is read using the data read operation, the page rendering flag is set to allow rendering, and the data request operation is continued to be executed so as to update the cached data in the local database based on the indicator metadata returned by the data request operation; If the cached data in the local database is not read using the data read operation, the page rendering flag is set to not allow rendering, and the indicator metadata returned by the data request operation is written to the local database as the cached data. After the indicator metadata is written, the page rendering flag is updated to allow rendering.

[0006] Optionally, determining the corresponding target rendering parameters based on the current data filtering conditions includes: Respond to one or more data filtering operations to determine the current data filtering conditions and compare the current data filtering conditions with historical filtering conditions; The change filtering conditions are determined based on the comparison results, and the change filtering conditions are written into a preset status object; If no new data filtering operation is received within the preset time window, the target rendering parameters are determined based on the filtering conditions in the preset state object.

[0007] Optionally, after determining the corresponding target rendering parameters based on the current data filtering conditions, the method further includes: Based on the chart configuration information, pre-configured target filtering conditions are determined; wherein, the target filtering conditions are pre-configured filtering combinations that do not have corresponding indicator metadata; Determine whether the target rendering parameters match the target filtering conditions. If they match, determine that there are no corresponding indicator parameters and directly set the chart corresponding to the current data filtering conditions as a preset empty chart.

[0008] Optionally, before reading the target metadata from the local database based on the business domain identifier when the chart container of the chart to be rendered meets the chart rendering conditions, the method further includes: Based on the chart configuration information, a placeholder space for the chart container of the chart to be rendered is created; the height of the placeholder space is a preset minimum height, and the placeholder space is used to determine the position coordinates of the chart to be rendered within the preset visible area; Register a viewport observer corresponding to the chart container to determine whether the chart container of the chart to be rendered meets the chart rendering conditions; the detection range of the viewport observer is the area within a preset pixel distance range outside the preset visible area.

[0009] Optionally, reading the target metadata from the local database based on the business domain identifier includes: The metric metadata is read from the local database based on the business domain identifier; Determine several rendering parameters among the target rendering parameters, and generate target keys according to the different types of the rendering parameters; Determine the chart type of the chart to be rendered, and determine the chart type transformation function corresponding to the chart type. Call the chart type transformation function to transform the indicator metadata into the data structure corresponding to the chart type to obtain the target metadata.

[0010] Optionally, the chart rendering method further includes: When the data reading operation fails, the chart to be rendered corresponding to the chart configuration information is directly determined as a preset empty state chart; When the data request operation fails, it is determined whether the local database contains the metric metadata corresponding to the current business domain identifier. If it does, the page rendering flag is kept set to allow rendering. Furthermore, when the version of the local database changes, all data in the local database is cleared, the page rendering flag is reset to disallow rendering, the metric metadata obtained by re-executing the data request operation is written into the local database, and the page rendering flag is updated to allow rendering.

[0011] Secondly, this application provides a chart rendering apparatus, comprising: The request parsing module is used to parse page access requests and determine the business domain identifier and chart configuration information corresponding to the page access request. The data acquisition module is used to execute data request operations and data read operations in parallel according to the business domain identifier, and generate page rendering marks based on the operation results of the data request operations and the data read operations; the data request operation is used to request corresponding indicator metadata from a preset server according to the business domain identifier, and the data read operation is used to read corresponding cached data from a local database according to the business domain identifier. The parameter determination module is used to determine the corresponding target rendering parameters based on the current data filtering conditions when the page rendering mark is set to allow rendering. The data reading module is used to determine the chart to be rendered based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, read the target metadata in the local database based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area. The chart rendering module is used to construct a corresponding configuration object based on the target rendering parameters and the target metadata, and to render the corresponding target chart using the chart rendering engine based on the configuration object.

[0012] Thirdly, this application provides an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned chart rendering method.

[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program that, when executed by a processor, implements the aforementioned chart rendering method.

[0014] This application can parse page access requests, determine the business domain identifier and chart configuration information corresponding to the page access request, and, based on the business domain identifier, execute in parallel a data request operation to request corresponding indicator metadata from a preset server based on the business domain identifier, and a data read operation to read corresponding cached data from a local database based on the business domain identifier. Then, based on the results of the data request and data read operations, a page rendering flag is generated. When the page rendering flag indicates that rendering is allowed, the corresponding target rendering parameters are determined based on the current data filtering conditions, and the chart to be rendered is determined based on the chart configuration information. When the chart container of the chart to be rendered meets the chart rendering conditions that the chart container is currently within a preset visible area or within a preset pixel distance range outside the preset visible area, the target metadata in the local database is read based on the business domain identifier. Then, based on the target rendering parameters and target metadata, a corresponding configuration object is constructed, and the corresponding target chart is rendered using the chart rendering engine based on the configuration object.

[0015] Based on the above technical solution, this application can simultaneously initiate data requests to the server and cache reads from the local database, generate page rendering markers based on the operation results, and shorten the page rendering waiting time by executing data request operations and data read operations in parallel. Furthermore, the rendering trigger condition for the chart to be rendered is set to be within a preset visible area or within a preset pixel distance from the visible area. Chart containers outside this range are not triggered for rendering. Compared to the method of synchronously rendering all charts when the page loads, this avoids invalid calculations for charts that are not currently visible to the user, prioritizes the rendering of visible charts with computing resources, reduces the consumption of computing resources during the chart rendering stage, and improves the rendering efficiency of charts. At the same time, by setting the preset pixel distance range, loading can be triggered in advance before the chart enters the visible area, further reducing the waiting time perceived by the user when scrolling the page. Attached Figure Description

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

[0017] Figure 1 A flowchart of a chart rendering method provided in this application; Figure 2 This application provides a rendering flowchart for the initial rendering of a chart. Figure 3 This application provides a rendering flowchart for a non-first-time chart rendering process; Figure 4 A rendering flowchart for chart rendering based on user filtering conditions is provided for this application; Figure 5 This application provides a rendering flowchart for chart rendering during page scrolling; Figure 6 A flowchart of a chart rendering exception handling scheme provided in this application; Figure 7 A schematic diagram of a chart rendering device provided in this application; Figure 8 This application provides a structural diagram of an electronic device. Detailed Implementation

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

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] In enterprise-level data dashboards and other application scenarios, a single page typically contains dozens of heterogeneous charts, and the metadata of the metrics that the charts rely on for rendering is enormous. Therefore, if all charts send independent data requests to the server every time the page loads or the filtering conditions change, it will cause a lot of redundant network overhead and waiting delays. Furthermore, all charts on the page are synchronously instantiated and rendered when the page is initialized, which consumes a lot of computing resources. This application can simultaneously send data requests to the server and read cached data from the local database, shortening the page rendering waiting time. Moreover, the rendering trigger condition for the chart to be rendered is set to be within a preset visible area or within a preset pixel distance from the visible area, which reduces the computing resource consumption during the chart rendering stage and improves the rendering efficiency of the charts.

[0021] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] It should be noted that the rendering process in this application is implemented based on a caching layer, a rendering scheduler, a viewport observer, and a data transformer. Specifically, it can be divided into a page orchestration layer (PageOrchestrator), a persistent cache layer (PersistentStorage), a cache coordinator layer (CacheCoordinator), a rendering scheduler layer (RenderScheduler), and a viewport lazy loading layer (ViewportObserver). The page orchestration layer is responsible for page lifecycle management, global state injection, and metric preloading coordination; the persistent cache layer is responsible for the initialization, reading, writing, and version management of the local database; the cache coordinator layer is responsible for multi-level cache read scheduling and data transformation of metrics, dimensions, and conditions; the rendering scheduler layer is responsible for debouncing scheduling, state guards, and rendering pipeline execution; and the viewport lazy loading layer is responsible for viewport visibility detection and on-demand triggering of chart component instantiation.

[0023] See Figure 1 As shown, an embodiment of the present invention discloses a chart rendering method, including: Step S11: Parse the page access request and determine the business domain identifier and chart configuration information corresponding to the page access request.

[0024] In this embodiment, when a user accesses the URL (Uniform Resource Locator) of the dashboard details page in a browser, the URL carries page parameters. For example, the URL in the page access request can carry the parameter `board=3`, which points to a specific business page, such as the "Margin Trading Business" page. After receiving the page access request, the PageOrchestrator layer parses the parameter information in the URL, looks up the page configuration information corresponding to the parameter in the pre-configured configuration table, and obtains the business domain identifier corresponding to the page through this configuration information, such as `domainId=189`, as well as the chart configuration information of all chart cards that need to be displayed on the page. The chart configuration information includes the chart type of each chart card (such as line chart, pie chart, progress chart, indicator card, data table, etc.), the indicator identifier, dimension information, and display style parameters required for the chart. Therefore, in this embodiment, it is first necessary to parse the page access request, determine the business domain identifier and chart configuration information corresponding to the page access request, and then clarify which business domain data the current page needs to obtain and which types of charts need to be rendered. As can be understood, the aforementioned dashboard, also known as a data dashboard, is a visualization tool used for data analysis and business monitoring. It can centrally present key indicators and data from different systems on a single screen through charts, graphs, indicator cards, etc., to achieve real-time data monitoring, analysis, anomaly warnings, and decision support. Furthermore, the aforementioned business domain identifier refers to a unique identifier used to identify a specific business domain. For example, in a BI system, the business domain identifier corresponding to the margin trading business is domainId=189, and different business domain identifiers correspond to different sets of indicator metadata.

[0025] Step S12: Based on the business domain identifier, execute data request operation and data read operation in parallel, and generate page rendering mark based on the operation results of the data request operation and the data read operation; the data request operation is used to request corresponding indicator metadata from a preset server based on the business domain identifier, and the data read operation is used to read corresponding cached data from the local database based on the business domain identifier.

[0026] In this embodiment, before the page orchestration layer renders the page frame, i.e., during the onBeforeMount page initialization phase, two parallel operations are initiated simultaneously: The first operation is a data request operation, which is executed asynchronously and does not block the rendering of the page frame. Specifically, based on the business domain identifier determined in step S11, a network request is initiated to a preset server to retrieve the full metric metadata of that business domain. For example, the full metric metadata contains hundreds of metric definitions and their associated dimension information, with the original data volume reaching several MB. The response time of this network request is typically between 500 milliseconds and 2 seconds, depending on the current network latency and server processing time. The second operation is a data read operation, which is executed synchronously and can return results immediately. Specifically, a corresponding cache key can be constructed based on the business domain identifier. The cache key adopts the naming convention of "{prefix}_{business domain identifier}", such as "ALL_INDICATORS_DOMAIN_ID_189", to ensure that the data of different business domains are completely isolated and do not interfere with each other. Then, the cache key is used to read whether the cached data of that business domain exists in the local database (IndexedDB). Furthermore, it's understandable that since the data request operation is asynchronous, it won't block the rendering of the page frame. Therefore, while the two operations are executing in parallel, the page frame (such as the top filter bar and side navigation) can begin rendering normally, but the chart area will temporarily display a "loading" placeholder state. Also, the aforementioned local database refers to a persistent storage database deployed on the client side (such as a browser), such as a client-side database like IndexedDB.

[0027] In one specific implementation, when cached data in the local database is not read using a data read operation, the page rendering flag is set to disallow rendering, and the metric metadata returned by the data request operation is written to the local database as cached data. After the metric metadata is written, the page rendering flag is updated to allow rendering. Figure 2As shown, on the first visit, there is no cached data locally. The chart rendering can only begin after the metric metadata is retrieved from the remote database. Therefore, if the cached data in the local database is not retrieved using a data read operation, it indicates that the user is visiting the page for the first time. Since there is no cached data for this business domain in the local database, the data read operation returns an empty result. At this time, the page rendering flag is set to disallow rendering (showCard=false), temporarily preventing the chart from starting to render. The system waits for the data request operation to retrieve the full metric metadata from the preset server. Once the data request operation successfully returns and obtains the full metric metadata, it is written to the local database based on the storage structure {cache key, data value, write timestamp}. The cache key uses the format {prefix}_{business domain identifier} (e.g., ALL_INDICATORS_DOMAIN_ID_189) to ensure that data from different business domains does not interfere with each other. After the write is complete, the page rendering flag is updated to allow rendering, notifying the chart container on the page that it can begin working.

[0028] In another specific implementation, when cached data is read from the local database using a data read operation, the page rendering flag is set to allow rendering, and the data request operation continues to be executed so that the cached data in the local database is updated based on the metric metadata returned by the data request operation. For example... Figure 3 As shown, when cached data is read from the local database using a data read operation, it indicates that the user has previously visited the page, and the local database already has complete metric metadata cached. At this point, the system sets the page rendering flag to allow rendering (showCard=true) and continues to execute data request operations in the background. Chart rendering can begin immediately after the page framework is rendered, without waiting for remote requests. Since the data read operation typically takes less than 10 milliseconds, while the network latency for data request operations is typically 500 milliseconds to 2 seconds, the page can begin chart rendering even before the data request operation returns. Therefore, it can be understood that the purpose of the continued background data request operation is no longer to provide data for this rendering, but to silently update the cached data in the local database. When the data request operation returns the latest metric metadata, the system writes it to the local database, overwriting the existing cached data. This update process is completely transparent to the user; the user will not perceive any loading status, interface flickering, or page changes. Furthermore, the updated cached data will take effect on the user's next visit, ensuring that the cached data does not age indefinitely. At the same time, if a data request fails due to network fluctuations or server malfunctions, it will not affect the normal use of the current page at all, because the current page always uses the local cached data.

[0029] It should be noted that the cached data in the local database is stored using a structured storage method. For metric metadata, a cache key built based on the business domain identifier is used for storage (e.g., ALL_INDICATORS_DOMAIN_ID_189) to ensure complete isolation of data from different business domains. In addition, user-customized configuration data (e.g., table column sorting) is stored using a separate cache key (e.g., DETAIL_BOARD_RANKING), managed separately from the metric metadata, and they do not interfere with each other.

[0030] Furthermore, in the caching architecture of this embodiment, a first-level memory cache, namely the L1 memory cache, can be maintained in runtime memory to store the chart consumption data after data transformation in the current session, including indicator data, dimension data, and filter condition data used in the current session of the chart. It is limited by the size of runtime memory, but its access speed is at the nanosecond level, enabling rapid data return. The local database, namely the L2 persistent cache, has a data storage capacity of hundreds of megabytes and can return data in milliseconds. It is mainly used for full indicator metadata and user-defined sorting configurations that need to be persistently stored across sessions. The preset server, namely the L3 remote data source, is the authoritative data source of the original indicator metadata controlled by the server. It can provide the latest and most complete data, but it needs to be obtained through network requests.

[0031] The three-level cache structure described above constitutes the three-level progressive cache structure in this embodiment. Each level has different performance characteristics and applicable scenarios. Cache reads are performed sequentially according to the priority of L1 memory cache, L2 local database, and L3 preset server. Data is returned as soon as a match is found at any level, without further searching, thus maximizing data acquisition efficiency. Correspondingly, the data writing rules are as follows: the original indicator metadata obtained from the L3 preset server is written to the L2 local database for persistent storage, and the chart consumption data after data transformation is written to the L1 memory cache for direct consumption during rendering. In this way, it can be ensured that the persistent cache stores the original indicator metadata, while the memory cache stores the chart consumption data after processing and transformation by business logic. The two levels are bridged by a composite key mapping and a chart type transformation function, achieving a reasonable separation between the original data and the consumption data.

[0032] Step S13: When the page rendering mark is set to allow rendering, determine the corresponding target rendering parameters based on the current data filtering conditions.

[0033] In this embodiment, once the page rendering flag is set to allow rendering, the corresponding target rendering parameters can be determined based on the current data filtering conditions. Specifically, users can perform data filtering operations through the global filter on the page. Filtering dimensions include, but are not limited to, date, region, branch, team, and employee. Each time a user performs a filtering operation, the corresponding filtering field in the global state is updated, forming the current data filtering conditions.

[0034] Specifically, it can respond to one or more data filtering operations to determine the current data filtering conditions, compare the current data filtering conditions with historical filtering conditions, and determine the modified filtering conditions based on the comparison results. The modified filtering conditions are then written to a preset state object. If no new data filtering operation is received within a preset time window, the target rendering parameters are determined based on the filtering conditions in the preset state object. In essence, when comparing the current data filtering conditions with historical filtering conditions, a deep equals comparison is used, comparing each parameter value in the filtering conditions field by field to determine if there is a substantial change. If the current data filtering conditions are completely identical to the historical filtering conditions, it means that the filtering conditions have not changed, and this operation is an invalid trigger, requiring no further rendering process. This effectively filters out invalid triggers that initiate a listener callback but whose filtering conditions have not actually changed. Furthermore, if the comparison result determines that a change exists, the modified filtering conditions are determined based on the comparison result, and the modified filtering conditions are written to the preset state object. As can be understood, in this embodiment, since all charts are listening for changes in global filter conditions, each change in filter conditions will simultaneously trigger the listener callbacks of all visible charts. Furthermore, the preset state object is a reactive state object, shared by all charts. Each filter operation modifies the corresponding field in this preset state object, and the changes are cumulative. Next, it is necessary to determine whether a new data filter operation has been received within a preset time window. If no new data filter operation has been received within the preset time window, the target rendering parameters are determined based on the filter conditions in the preset state object. For example, the default value of the preset time window can be set to 100 milliseconds. When the first filter operation is triggered, the system starts a 100-millisecond waiting window (the timer begins counting down). If a new filter operation occurs within this waiting window, the timer is reset, and the 100-millisecond countdown restarts from the current moment. Simultaneously, the rendering request triggered by the previous filter operation is overwritten. This continues until no new filter operation occurs within 100 milliseconds after a certain filter operation, at which point the timer expires. The final filter conditions in the preset state object at this point are then used to determine the target rendering parameters, and a rendering is performed.

[0035] See Figure 4As shown, the following implementation uses a specific scenario to illustrate the process: a user quickly performs three consecutive filtering operations: the first operation (time t=0ms) changes the date to 2025-03-15; the second operation (time t=30ms) changes the branch office to B001; and the third operation (time t=60ms) changes the team to T003. During the first operation, the date field is updated, the global filtering conditions change, the change detection passes, and the system starts a 100ms wait window. The second operation occurs 30ms after the first operation. At this time, the wait window has not yet expired, the system resets the timer and restarts the 100ms countdown, overwriting the rendering request of the first operation. The third operation occurs 30ms after the second operation, and the timer is also reset. All changes (date, branch, team) from the three operations are cumulatively written into the preset state object. 100 milliseconds after the third operation (i.e., t=160ms), the timer expires, and the system uses the final preset state object (date=2025-03-15, branch=B001, team=T003) to determine the target rendering parameters and execute a single rendering. Therefore, the three operations trigger only one actual rendering; the intermediate transitional states are not rendered, avoiding invalid calculations and interface flickering. Accordingly, the aforementioned target rendering parameters include, but are not limited to: role type (determined based on the lowest level of the filtering conditions, e.g., when "team" has a value, the role type is "team"), time granularity (e.g., day, week, month), dimension filtering conditions (only filtering parameters matching the current role type are retained, removing higher-level conditions), and date filtering range (calculated based on the time granularity, including the corresponding start and end dates).

[0036] Furthermore, in this embodiment, after determining the corresponding target rendering parameters based on the current data filtering conditions, it can also determine pre-configured target filtering conditions that do not have corresponding indicator metadata based on the chart configuration information, and determine whether the target rendering parameters match the target filtering conditions. If they match, it is determined that there are no corresponding indicator parameters, and the chart corresponding to the current data filtering conditions is directly determined as a preset empty state chart. In other words, after determining the corresponding target rendering parameters based on the current data filtering conditions, a state guard check can also be performed, that is, a pre-check is performed before the rendering pipeline starts, and it is determined whether to enter the rendering process according to business rules. Specifically, the pre-configured target filtering conditions can be determined based on the chart configuration information. These target filtering conditions are declared in advance during the system configuration phase, indicating that there are no corresponding indicator metadata under the combination of filtering conditions. If the target rendering parameters match the no-data filtering combination, the corresponding chart is directly determined as a preset empty state chart, and the subsequent process is skipped; if the no-data filtering combination is not matched, the corresponding data entry is retrieved from the full indicator metadata based on the target rendering parameters. If no matching indicator parameter is found, the corresponding chart is determined as a preset empty state chart. For example, in the preset no-data filter combination, "Branch Office = B099" is pre-marked as having no data. When a user selects "Branch Office = B099", an empty state is displayed directly without querying the database. If a user selects "Branch Office = B001, Team = T999", since T999 is a newly established team and its configuration doesn't pre-mark it as having no data, the system searches the full metric library for the metric corresponding to "B001 + T999". Finding no metric definition for this team, an empty state is also displayed directly, and no further rendering is performed. In this way, the state guard can advance the determination of no data from after rendering to before rendering, avoiding unnecessary data loading and chart rendering overhead. For example, if a department hasn't yet implemented a certain function, there might be no relevant data under the corresponding filter condition. This filter condition is pre-marked in the system configuration as "noDataForSelected". Then, it's determined whether the target rendering parameters contain parameters corresponding to the target filtering conditions. If they do, meaning the current combination of filtering conditions is pre-labeled as a no-data scenario, the chart corresponding to that target filtering condition is directly designated as a preset empty chart, skipping the complete data loading and chart rendering process, and directly displaying the empty interface. This way, the no-data scenario can be predicted before rendering, saving computational resources. Furthermore, when the values ​​of certain filtering dimensions (such as region, branch, team, employee) in the global filter are empty, corresponding processing can be performed, that is, empty filtering conditions are pushed into default values, and normal rendering is performed using the default conditions, ensuring that meaningful data can still be displayed even when filtering conditions are incomplete.

[0037] Step S14: Determine the chart to be rendered based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, read the target metadata in the local database based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area.

[0038] In this embodiment, the chart to be rendered can be determined based on the chart configuration information. When the chart container of the chart to be rendered meets the chart rendering conditions, the target metadata in the local database is read based on the business domain identifier. That is, in this embodiment, all the charts to be rendered on the current page can be determined based on the chart configuration information obtained in step S11. For example, a dashboard details page may contain more than 20 chart cards. Before reading the target metadata in the local database based on the business domain identifier, it is also necessary to create a placeholder space for the chart container of the chart to be rendered based on the chart configuration information. The height of the placeholder space is a preset minimum height, and the placeholder space is used to determine the position coordinates of the chart to be rendered within a preset visible area. A viewport observer corresponding to the chart container is registered for the area outside the preset visible area within a preset pixel distance range, so as to use the viewport observer to determine whether the chart container of the chart to be rendered meets the chart rendering conditions.

[0039] Specifically, the first step is to create a placeholder space for the chart container to be rendered based on the chart configuration information. The height of this placeholder space is a preset minimum height. In one specific embodiment, this preset minimum height can be set to 1 pixel (1px). By setting a preset minimum height, it is ensured that the chart container occupies space in the DOM (Document Object Model) tree, allowing the viewport observer to correctly calculate its position and size. If the chart container has no height, the viewport observer may not be able to detect its existence or accurately calculate its distance relative to the preset visible area. Thus, by setting a preset minimum height of 1 pixel, each chart container can be effectively monitored by the viewport observer without occupying too much page space. Next, the viewport observer corresponding to the chart container is registered. Specifically, a viewport observer instance based on the browser's native IntersectionObserver API (Application Programming Interface) can be created for each chart container, and the detection range of the viewport observer is set to the area within a preset pixel distance outside the preset visible area. In one specific embodiment, the preset pixel distance can be set to 200 pixels, meaning the viewport observer's rootMargin parameter can be configured to "200px". Therefore, when the chart container is 200 pixels away from the edge of the preset visible area (i.e., the browser viewport), the viewport observer will detect that the container is about to become visible and trigger the corresponding callback. In this way, a preloading window can be formed through the preset pixel distance, achieving the effect of starting loading as soon as the chart becomes visible. Therefore, when judging the above chart rendering conditions, the viewport observer continuously monitors the position of the chart container it is responsible for relative to the preset visible area. When the chart container is currently within the preset visible area, or outside the preset visible area but within the preset pixel distance range (e.g., 200 pixels), the viewport observer determines that the chart container meets the chart rendering conditions and triggers the chart loading process.

[0040] See Figure 5As shown, this embodiment will be illustrated with a specific scrolling loading scenario: When the user starts scrolling down the page, the browser continuously calculates the position of each chart container relative to the preset visible area. When a chart container (such as chart A) is still 200 pixels away from the edge of the preset visible area, the user cannot see the chart yet, but will see it after scrolling a short distance. Therefore, the viewport observer detects that the container has entered the extended viewport range, that is, the detection range formed by the preset visible area plus the preset pixel distance, and determines that the chart container meets the chart rendering conditions. At this point, the viewport observer marks Chart A's state as "loading," and if the user happens to scroll quickly to this position, they will see a brief loading indicator instead of a blank screen. Then, the chart component corresponding to Chart A, namely the ChartCard component, is instantiated, and this component is created and mounted into the chart container. At this point, a complete chart component is created, including its internal data variables, rendering methods, event listeners, etc., all of which are ready. After instantiation, the unobserve method is called, and the viewport observer stops observing the container of Chart A and no longer listens for changes in the container's position, ensuring that Chart A will never be reloaded during subsequent scrolling, i.e., one observation, one loading, and then stopping observation.

[0041] Furthermore, when reading target metadata from the local database based on the business domain identifier, the indicator metadata in the local database can be read based on the business domain identifier, and several rendering parameters in the target rendering parameters can be determined. Target keys are generated according to different types of rendering parameters, thereby determining the chart type of the chart to be rendered, and determining the chart type transformation function corresponding to the chart type. The chart type transformation function is then called to transform the indicator metadata into the data structure corresponding to the chart type to obtain the target metadata. Specifically, firstly, a corresponding cache key (such as ALL_INDICATORS_DOMAIN_ID_189) is constructed based on the business domain identifier. The full indicator metadata of this business domain is read from the local database. Since the indicator metadata has already been written to the local database in step S12, this read directly hits the cache, typically taking less than 10 milliseconds. Secondly, several rendering parameters in the target rendering parameters are determined, and target keys are generated according to different types of rendering parameters. The aforementioned target key is a composite key, which is composed of the values ​​of multiple rendering parameters. For example, when the time granularity is "day" and the role level is "team," the target key can be a combination of "day granularity × team." This target key can then be used to find the indicator definition matching the current filtering context from the full indicator metadata. Next, the chart type to be rendered is determined, along with the corresponding chart type transformation function. It's understandable that different chart types require different data structures. For instance, an index card might require a two-level array structure, where the outer array corresponds to different index cards, and the inner array corresponds to the specific indicator value and comparison value to be displayed in each card; a progress chart might require a four-segment structure, dividing the progress value into four intervals for display; a table requires a row-column matrix structure, expanding the indicator data into table rows and column definitions; a line chart requires a time series structure, arranging the indicator data into an ordered sequence of data points along the time dimension; a bar chart requires a categorized aggregation structure; and a pie chart requires a categorized percentage structure, calculating the proportion of each category in the total, etc. Therefore, the corresponding chart type transformation function can be called to transform the raw indicator data extracted from the full indicator metadata into the data structure corresponding to the chart type, thereby obtaining the target metadata.

[0042] It's important to note that the input to the above data transformation process is the full set of indicator metadata read from the local database. The transformer first uses the target key to locate the matching indicator definition set within the current filtering context from the full data. Then, it selects the appropriate transformation strategy based on the chart type to perform a structural transformation. The transformed target metadata is directly used for subsequent configuration object construction, and its data structure fully matches the requirements of the chart rendering engine. Furthermore, during the data transformation process, the data transformer is also responsible for handling dimensional relationships. For example, when indicator dimensions have cross-table relationships (i.e., the case of related dimensions relTable), the data transformer needs to parse this relationship and obtain the correct dimension data. In addition, the data transformer is also responsible for handling the priority ordering of filtering conditions, ensuring that the construction logic of the filtering conditions matches the current role type and time granularity.

[0043] It should be further explained that in this embodiment, all charts on the page share the same business domain's metric metadata cache. The full metric metadata fetched from the preset server the first time is reused by all charts. Each chart only extracts the part it needs from the full data and transforms the data structure according to its own chart type. Therefore, in a cold start scenario, regardless of the number of charts on the page, there is only one network request to the preset server. Subsequent data retrieval for all charts is done from the local cache, which can solve the problem of a large amount of repetitive network overhead caused by making independent API requests for each individual chart.

[0044] Step S15: Construct a corresponding configuration object based on the target rendering parameters and the target metadata, and use the chart rendering engine to render the corresponding target chart based on the configuration object.

[0045] In this embodiment, the target metadata obtained in step S14 and the target rendering parameters determined in step S13 can be assembled into a complete configuration object that can be directly consumed by the chart rendering engine. The configuration object includes, but is not limited to: chart type identifier, chart style parameters (color scheme, line thickness, font size, etc.), date filtering range (start and end dates calculated based on time granularity), dimension filtering conditions (e.g., team number = T003), chart display configuration (e.g., axis range for line charts, label format for pie charts, column definitions for tables, etc.), and the transformed target metadata itself. Through the configuration object assembly process `updateProps`, the scattered rendering parameters and target metadata can be integrated into a complete configuration structure that can be directly consumed by the rendering engine. For example, the start and end dates of the date filtering range can be calculated based on the current time granularity, and the parameters to be retained in the dimension filtering conditions can be determined based on the role type (e.g., when the role type is "team" level, the filtering conditions only retain the team number, removing higher-level conditions such as region and branch). This information, along with the chart style parameters and target metadata, can be encapsulated into a configuration object. Once the configuration object is constructed, it is submitted to the chart rendering engine for the actual chart drawing operation (preview). The chart rendering engine selects the corresponding rendering strategy based on the chart type identifier in the configuration object and uses the target metadata and rendering parameters to complete the chart binding and rendering. After rendering is complete, a signal indicating that data loading is complete is emitted. Figure 5 The `emit('data-loaded')` event is shown, which updates the information displayed on the chart card, such as the latest data date. In this way, this embodiment can decompose the chart update process into three sequential steps: `resetData`, `updateProps`, and `preview`. `resetData` retrieves the latest metrics, dimensions, and conditional data from the cache layer; `updateProps` transforms the data into configuration objects that the rendering engine can consume (including chart type, style, filter conditions, time range, etc.); `preview` calls the rendering engine to perform the actual chart drawing. Furthermore, by constructing a rendering pipeline, the rendering process is structured into an observable and interruptible pipeline.

[0046] It should be noted that in this embodiment, when the data read operation fails, the chart to be rendered corresponding to the chart configuration information can be directly determined as a preset empty chart; and when the data request operation fails, it is determined whether the indicator metadata corresponding to the current business domain identifier exists in the local database. If it exists, the page rendering flag is kept set to allow rendering; and when the version of the local database changes, all data in the local database is cleared, the page rendering flag is reset to disallow rendering, and the indicator metadata obtained by re-executing the data request operation is written to the local database, and the page rendering flag is updated to allow rendering. For details, see [link to documentation]. Figure 6 As shown, this embodiment can also handle chart rendering anomalies to ensure the resilience of the system when anomalies occur at each layer.

[0047] In one specific implementation, if the data read operation fails—that is, if the local database (such as IndexedDB) encounters an error, such as being disabled by the browser or having insufficient storage quota—the exception is caught using a try-catch block, and the system is downgraded to returning empty data. In other words, the chart to be rendered corresponding to the chart configuration information is directly set to a preset empty state chart. The chart displays an empty interface but does not cause page crashes or JavaScript runtime errors. This degradation strategy ensures that even if the local caching layer is completely unavailable, the page can still be rendered in a predictable manner.

[0048] In another specific implementation, if a data request operation fails, i.e., an anomaly occurs at the network layer, such as network fluctuations or a pre-set server failure causing the remote request to fail, the system checks whether the metric metadata corresponding to the current business domain identifier exists in the local database. If it exists (i.e., in a warm start scenario), the page rendering is marked as allowed, and the page is rendered normally using the existing cached data locally, completely unaffected by network anomalies. If the cached data does not exist in the local database (i.e., in a cold start scenario, the network also fails), the page remains in a loading placeholder state, and the user can retry by refreshing the page.

[0049] In another specific implementation, if the chart rendering engine malfunctions, that is, if an error occurs during the rendering of a single chart, the failure of rendering a single chart will not affect the normal operation of other charts on the same page. The area of ​​the chart with the malfunction will remain blank or display an error message, while the remaining charts will continue to be rendered and displayed normally.

[0050] In another specific implementation, the version of the local database changes. For example, when the version number of the local database (IndexedDB) is upgraded, the system triggers the `onupgradeneeded` event. At this time, a "clean-update" strategy is adopted, which involves clearing all data in the local database and resetting the page rendering flag to disallow rendering. Then, the system re-executes the data request operation, retrieves the latest metric metadata from the preset server, writes it to the local database, and updates the page rendering flag to allow rendering. This avoids incompatibility between the old and new data formats, ensures that the system can still operate normally after the version upgrade, and re-executes the cold start process the next time a user accesses the system, fetching data from the preset server again and writing it to the local database.

[0051] In another specific implementation, the filter condition is null. For example, when the values ​​of certain filter dimensions (such as region, branch, team, employee) in the global filter are null, the null filter condition is pushed into the default value (such as the default headquarters identifier), and the default condition is used for normal rendering instead of directly displaying the null state or an error.

[0052] In this way, through the degradation strategy in the above implementation, any single-layer anomaly will not affect the normal operation of other layers, ultimately ensuring that users can always see the normal page state. Even if some charts are displayed as empty due to anomalies, the page as a whole will not be blank or crash.

[0053] Based on the above technical solutions, this embodiment can execute data request and data read operations in parallel and generate page rendering markers based on the operation results. In a warm start scenario, it can skip remote network requests and directly use local cached data to start rendering, effectively shortening the first screen's interactive time. In a cold start scenario, it does not block the rendering of the page framework, improving the user's perceived response speed. At the same time, through debouncing merging, change detection, and no-data prediction, it can efficiently execute high-frequency user filtering operations, avoiding invalid rendering in intermediate transition states and useless calculations in known no-data scenarios. It can also implement rendering based on the viewport observer, so that charts are only instantiated and rendered when they are about to enter the user's viewport. Charts that have not entered the viewport do not create component instances and DOM nodes, effectively reducing computing resource consumption and preventing the rendering of the first screen's visible charts from being slowed down by a large number of invisible charts. In this embodiment, regardless of how many charts are on the page, the remote request is always only once, and all charts share the same cached data, significantly reducing network overhead.

[0054] Based on the technical solutions in the above embodiments, this embodiment will further explain the above chart rendering method in conjunction with specific application scenarios.

[0055] See Figure 2As shown, this embodiment provides a rendering process for the first time a chart is rendered (i.e., a cold start scenario). In the cold start scenario, when a user visits the dashboard details page for the first time, there is no cached data for that business domain in the local database. If the user accesses the details page URL in the browser, the page orchestration layer parses the URL parameters to obtain the business domain identifier and chart configuration information. Before the page frame is rendered, the page orchestration layer executes data request operations and data read operations in parallel. The data request operation asynchronously sends a request to a preset server to retrieve all metric metadata; the data read operation synchronously reads from the local database. It can be understood that since it is the first visit, there is no cached data in the local database, the data read operation returns an empty result, and the system sets the page rendering flag to disallow rendering. At this time, the page frame can start rendering normally, but the chart area displays a "loading" placeholder state. After the data request operation successfully retrieves all metric metadata from the preset server, it writes the data to the local database. The storage structure includes a cache key, data value, and write timestamp. After the write is completed, the page rendering flag is updated to allow rendering, notifying the chart container that it can start working. After the page framework is rendered, several chart containers visible on the first screen have registered viewport observers. Since these containers are located within the preset visible area, meeting the chart rendering conditions, and the page rendering flag is set to allow rendering, loading is triggered immediately. Each chart sequentially reads the metric metadata from the local database, transforms it into the data structure corresponding to the chart type, constructs a configuration object, and calls the chart rendering engine to draw the chart. If the user scrolls the page subsequently, the charts are loaded progressively. Chart containers below the first screen, although existing in the DOM, are not loaded because they are outside the preset visible area and its preset pixel distance. When the user scrolls down, the viewport observer detects a new chart container entering the extended viewport range, triggering the loading of that chart and executing the above rendering process. It should be noted that since all charts share the same cached data in the local database, subsequent chart data retrieval does not require further requests to the preset server; it only needs to be read from the local database.

[0056] See Figure 3As shown, this embodiment also provides a rendering process for charts not being rendered for the first time (i.e., a warm start scenario). In the warm start scenario, when a user revisits the dashboard details page, the local database already has complete cached metric metadata. Therefore, when performing a data read operation to read the local database, since the user has previously visited the page and the local database already has complete cached data, valid data is immediately returned, and the page rendering flag is set to allow rendering. Simultaneously, the data request operation is executed asynchronously in the background for silent cache updates. After the page framework is rendered, the chart container visible on the first screen is triggered to load. The subsequent chart rendering process is the same as in the cold start scenario and will not be described in detail here. However, in this scenario, the network request for the data request operation may only return after the user has seen the complete page and charts. At this time, the latest returned metric metadata is written to the local database to update the cache.

[0057] See Figure 5 As shown in the figure, this application embodiment provides a rendering process for chart rendering during page scrolling. Figure 5 In the lazy loading scenario shown, the page has finished loading, and the user begins scrolling down. When the container of chart A is 200 pixels from the edge of the preset visible area, the viewport observer detects that the container has entered the preset pixel distance range, determines that the chart rendering conditions are met, marks chart A as "loading," instantiates the chart component of chart A, and then immediately stops observing the container (unobserve) to ensure that it is not triggered repeatedly. After the component instance of chart A is mounted, the rendering process is automatically executed. Then the user continues scrolling, and subsequent charts enter the extended viewport in turn. The viewport observer detects new chart containers entering the preset pixel distance range and executes the corresponding rendering process until all charts are loaded. In this way, the viewport observer can be combined with the rendering pipeline. Before the chart component is instantiated (i.e., before entering the viewport), no objects or DOM nodes are created, effectively saving runtime memory and processor computing resources.

[0058] See Figure 7 As shown in the illustration, this application also discloses a chart rendering apparatus, including: Request parsing module 11 is used to parse page access requests and determine the business domain identifier and chart configuration information corresponding to the page access request; The data acquisition module 12 is used to execute data request operations and data read operations in parallel according to the business domain identifier, and generate page rendering marks based on the operation results of the data request operations and the data read operations; the data request operation is used to request corresponding indicator metadata from a preset server according to the business domain identifier, and the data read operation is used to read corresponding cached data from a local database according to the business domain identifier. Parameter determination module 13 is used to determine the corresponding target rendering parameters based on the current data filtering conditions when the page rendering mark is set to allow rendering; Data reading module 14 is used to determine the chart to be rendered based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, read the target metadata in the local database based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area. The chart rendering module 15 is used to construct a corresponding configuration object based on the target rendering parameters and the target metadata, and to render the corresponding target chart using the chart rendering engine based on the configuration object.

[0059] In this embodiment, before rendering the chart, a data request to the server and a cache read from the local database can be initiated simultaneously. A page rendering marker is generated based on the operation results. By executing the data request and data read operations in parallel, the waiting time for page rendering is shortened. Furthermore, the rendering trigger condition for the chart to be rendered is set to be within a preset visible area or within a preset pixel distance from the visible area. Chart containers outside this range are not rendered temporarily, so that computing resources are prioritized for rendering visible charts, reducing the consumption of computing resources in the chart rendering stage and improving the rendering efficiency of the chart. At the same time, by setting the preset pixel distance range, loading can be triggered in advance before the chart enters the visible area, further reducing the waiting time perceived by the user when scrolling the page.

[0060] In some specific embodiments, the data acquisition module 12 specifically includes: The first flag setting unit is used to set the page rendering flag to allow rendering when the cached data in the local database is read using the data reading operation, and continue to execute the data request operation so as to update the cached data in the local database based on the indicator metadata returned by the data request operation. The second flag setting unit is used to set the page rendering flag to disallow rendering when the cached data in the local database is not read using the data reading operation, and to write the indicator metadata returned by the data request operation as the cached data into the local database, so as to update the page rendering flag to allow rendering after the indicator metadata is written.

[0061] In some specific embodiments, the parameter determination module 13 specifically includes: A condition determination unit is used to respond to one or more data filtering operations to determine the current data filtering conditions and compare the current data filtering conditions with historical filtering conditions. The condition writing unit is used to determine the change filtering conditions based on the comparison results and write the change filtering conditions into a preset state object; The first parameter determination unit is used to determine the target rendering parameters based on the filtering conditions in the preset state object if no new data filtering operation is received within the preset time window.

[0062] In some specific embodiments, the chart rendering device further includes: The condition determination module is used to determine pre-configured target filtering conditions based on the chart configuration information; wherein, the target filtering conditions are pre-configured filtering combinations that do not have corresponding indicator metadata; The condition matching module is used to determine whether the target rendering parameters match the target filtering conditions. If they match, it is determined that there are no corresponding indicator parameters, and the chart corresponding to the current data filtering conditions is directly determined as a preset empty state chart.

[0063] In some specific embodiments, the chart rendering device further includes: The placeholder space creation module is used to create a placeholder space for the chart container of the chart to be rendered based on the chart configuration information; the height of the placeholder space is a preset minimum height, and the placeholder space is used to determine the position coordinates of the chart to be rendered within the preset visible area; The observer registration module is used to register the viewport observer corresponding to the chart container, so as to use the viewport observer to determine whether the chart container of the chart to be rendered meets the chart rendering conditions; the detection range of the viewport observer is the area within a preset pixel distance range outside the preset visible area.

[0064] In some specific embodiments, the data reading module 14 specifically includes: The data reading unit is used to read the indicator metadata from the local database based on the business domain identifier; The second parameter determination unit is used to determine several rendering parameters among the target rendering parameters, and generate target keys according to the different types of the rendering parameters; The data transformation unit is used to determine the chart type of the chart to be rendered, determine the chart type transformation function corresponding to the chart type, and call the chart type transformation function to transform the indicator metadata into the data structure corresponding to the chart type to obtain the target metadata.

[0065] In some specific embodiments, the chart rendering device further includes: The chart determination module is used to directly determine the chart to be rendered corresponding to the chart configuration information as a preset empty state chart when the data reading operation fails. The tag retention module is used to determine whether the metric metadata corresponding to the current business domain identifier exists in the local database when the data request operation fails. If it exists, the page rendering tag is kept as allowed to render. The tag update module is used to clear all data in the local database, reset the page rendering tag to disallow rendering, write the indicator metadata obtained by re-executing the data request operation into the local database, and update the page rendering tag to allow rendering when the version of the local database changes.

[0066] Furthermore, embodiments of this application also disclose an electronic device, Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0067] Figure 8 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the graph rendering method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0068] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0069] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0070] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the graph rendering method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0071] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed chart rendering method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0072] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0073] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0074] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

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

[0076] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A chart rendering method, characterized in that, include: Parse the page access request to determine the business domain identifier and chart configuration information corresponding to the page access request; Based on the business domain identifier, data request operations and data read operations are executed in parallel, and page rendering tags are generated based on the operation results of the data request operations and the data read operations; The data request operation is used to request corresponding indicator metadata from a preset server based on the business domain identifier, and the data read operation is used to read corresponding cached data from a local database based on the business domain identifier. When the page rendering flag is set to allow rendering, the corresponding target rendering parameters are determined based on the current data filtering conditions; The chart to be rendered is determined based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, the target metadata in the local database is read based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area. Based on the target rendering parameters and the target metadata, a corresponding configuration object is constructed, and the corresponding target chart is rendered using the chart rendering engine based on the configuration object.

2. The chart rendering method according to claim 1, characterized in that, The generation of page rendering tags based on the operation results of the data request operation and the data read operation includes: When the cached data in the local database is read using the data read operation, the page rendering flag is set to allow rendering, and the data request operation is continued to be executed so as to update the cached data in the local database based on the indicator metadata returned by the data request operation; If the cached data in the local database is not read using the data read operation, the page rendering flag is set to not allow rendering, and the indicator metadata returned by the data request operation is written to the local database as the cached data. After the indicator metadata is written, the page rendering flag is updated to allow rendering.

3. The chart rendering method according to claim 1, characterized in that, The process of determining the corresponding target rendering parameters based on the current data filtering conditions includes: Respond to one or more data filtering operations to determine the current data filtering conditions and compare the current data filtering conditions with historical filtering conditions; The change filtering conditions are determined based on the comparison results, and the change filtering conditions are written into a preset status object; If no new data filtering operation is received within the preset time window, the target rendering parameters are determined based on the filtering conditions in the preset state object.

4. The chart rendering method according to claim 3, characterized in that, After determining the corresponding target rendering parameters based on the current data filtering conditions, the process also includes: Based on the chart configuration information, pre-configured target filtering conditions are determined; wherein, the target filtering conditions are pre-configured filtering combinations that do not have corresponding indicator metadata; Determine whether the target rendering parameters match the target filtering conditions. If they match, determine that there are no corresponding indicator parameters and directly set the chart corresponding to the current data filtering conditions as a preset empty chart.

5. The chart rendering method according to claim 1, characterized in that, Before reading the target metadata from the local database based on the business domain identifier when the chart container of the chart to be rendered meets the chart rendering conditions, the process further includes: Based on the chart configuration information, a placeholder space for the chart container of the chart to be rendered is created; the height of the placeholder space is a preset minimum height, and the placeholder space is used to determine the position coordinates of the chart to be rendered within the preset visible area; Register a viewport observer corresponding to the chart container to determine whether the chart container of the chart to be rendered meets the chart rendering conditions; the detection range of the viewport observer is the area within a preset pixel distance range outside the preset visible area.

6. The chart rendering method according to claim 1, characterized in that, The step of reading the target metadata from the local database based on the business domain identifier includes: The metric metadata is read from the local database based on the business domain identifier; Determine several rendering parameters among the target rendering parameters, and generate target keys according to the different types of the rendering parameters; Determine the chart type of the chart to be rendered, and determine the chart type transformation function corresponding to the chart type. Call the chart type transformation function to transform the indicator metadata into the data structure corresponding to the chart type to obtain the target metadata.

7. The chart rendering method according to any one of claims 1 to 6, characterized in that, Also includes: When the data reading operation fails, the chart to be rendered corresponding to the chart configuration information is directly determined as a preset empty state chart; When the data request operation fails, it is determined whether the local database contains the metric metadata corresponding to the current business domain identifier. If it does, the page rendering flag is kept set to allow rendering. Furthermore, when the version of the local database changes, all data in the local database is cleared, the page rendering flag is reset to disallow rendering, the metric metadata obtained by re-executing the data request operation is written into the local database, and the page rendering flag is updated to allow rendering.

8. A chart rendering device, characterized in that, include: The request parsing module is used to parse page access requests and determine the business domain identifier and chart configuration information corresponding to the page access request. The data acquisition module is used to execute data request operations and data read operations in parallel according to the business domain identifier, and generate page rendering marks based on the operation results of the data request operations and the data read operations; The data request operation is used to request corresponding indicator metadata from a preset server based on the business domain identifier, and the data read operation is used to read corresponding cached data from a local database based on the business domain identifier. The parameter determination module is used to determine the corresponding target rendering parameters based on the current data filtering conditions when the page rendering mark is set to allow rendering. The data reading module is used to determine the chart to be rendered based on the chart configuration information, and when the chart container of the chart to be rendered meets the chart rendering conditions, read the target metadata in the local database based on the business domain identifier; the chart rendering conditions are that the chart container of the chart to be rendered is currently located within a preset visible area or within a preset pixel distance range outside the preset visible area. The chart rendering module is used to construct a corresponding configuration object based on the target rendering parameters and the target metadata, and to render the corresponding target chart using the chart rendering engine based on the configuration object.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the chart rendering method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, implements the chart rendering method as described in any one of claims 1 to 7.

Images