Page list data loading method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of computer software development, can be applied to the field of science and technology finance / digital medical treatment, and discloses a page list data loading method and device, an electronic device and a storage medium. The method comprises the following steps: rendering a page list through initial list data, and configuring a sentinel observation element at the bottom of the list; determining a target visible area and an intersection trigger condition according to target scroll container information, loading advance information and an intersection proportion threshold value; configuring observation parameters based on the target visible area and the intersection trigger condition, and creating a viewport intersection observation instance; observing the sentinel observation element through the viewport intersection observation instance, and obtaining intersection state information relative to the target visible area; when the intersection state information meets the trigger condition, requesting new list data in combination with data loading state and paging information, and updating the page list and the observation state of the sentinel observation element according to the new list data. The method improves the list loading trigger accuracy and the page fluency.

Description

Technical Field

[0001] This application relates to the field of computer software development technology and can be applied to the fields of financial technology / digital healthcare, and in particular to a method, apparatus, electronic device and storage medium for loading page list data. Background Technology

[0002] As the scale of business data carried by web applications continues to increase, list displays have become an important form of page information presentation. In business scenarios such as fintech, healthcare, and content display, pages typically need to display a large amount of record-type, message-type, or detailed data. Loading all the data at once can easily lead to problems such as excessively long initial loading time, increased page rendering pressure, and slowed interactive response. Therefore, traditional web pages usually adopt a batch loading method, gradually acquiring subsequent data as the user continuously browses the list content. When determining the timing of subsequent data loading, traditional list loading methods typically require comprehensive calculations based on parameters such as page scroll position, visible area height, list content height, scroll container boundary, and bottom distance. Due to differences in the layout structure, scroll container hierarchy, list nesting method, and terminal display size of different pages, the above calculation process is easily affected by changes in page structure and rendering state, making it difficult to maintain stable loading trigger conditions. Especially when the list is located in a partial scroll area, the page has dynamic content insertion, asynchronous image rendering, or changes in container height, loading judgment may result in problems such as premature triggering, delayed triggering, repeated triggering, or failure to trigger. Meanwhile, when users scroll quickly or swipe frequently, the page needs to continuously handle scrolling state changes and repeatedly execute logic such as position acquisition, distance calculation, and boundary judgment, which can easily increase front-end runtime overhead and affect page rendering frame rate and interaction continuity. In addition, traditional implementations usually require additional handling of boundary logic such as throttling, debouncing, critical distance, loading locking, no more data state, and abnormal return state, which increases the complexity of the code structure and the subsequent maintenance and adaptation costs are high. Summary of the Invention

[0003] The main technical problem addressed by the implementation method of this application is that traditional list loading technology suffers from inaccurate loading triggering, high page runtime overhead, and complex boundary state handling when determining the timing of data loading.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a page list data loading method, comprising: rendering a page list using acquired initial list data; configuring a sentinel observation element in the bottom area of ​​the page list according to the list display area of ​​the page list; determining a target visible area and a preset intersection trigger condition based on the target scroll container information, loading lead information, and intersection ratio threshold corresponding to the page list; configuring observation parameters based on the target visible area and the preset intersection trigger condition, and creating a viewport intersection observation instance based on the observation parameters and preset intersection state callback logic; observing the sentinel observation element through the viewport intersection observation instance to obtain intersection state information of the sentinel observation element relative to the target visible area; when the intersection state information satisfies the preset intersection trigger condition, sending a list data loading request to the server according to the data loading state and pagination information corresponding to the page list, and receiving newly added list data returned by the server; updating the page list according to the newly added list data, and updating the observation state of the sentinel observation element according to the data remaining information corresponding to the newly added list data.

[0005] To solve the above-mentioned technical problems, the second technical solution adopted in this application is: providing a page list data loading device, including: an initial rendering configuration module, used to render a page list by acquiring initial list data, and configure sentinel observation elements in the bottom area of ​​the page list according to the list display area of ​​the page list; a trigger condition determination module, used to determine a target visible area and a preset intersection trigger condition according to the target scroll container information, loading advance information and intersection ratio threshold corresponding to the page list; and an observation instance creation module, used to configure observation parameters according to the target visible area and the preset intersection trigger condition, and to call back based on the observation parameters and the preset intersection state. The system includes: a viewport intersection observation instance creation module; an intersection state acquisition module for observing the sentinel observation element through the viewport intersection observation instance and acquiring the intersection state information of the sentinel observation element relative to the target visible area; a load request sending module for sending a list data loading request to the server based on the data loading status and pagination information corresponding to the page list when the intersection state information meets the preset intersection triggering condition, and receiving the newly added list data returned by the server; and a list state update module for updating the page list based on the newly added list data and updating the observation state of the sentinel observation element based on the data remaining information corresponding to the newly added list data.

[0006] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the page list data loading method as described above.

[0007] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device performs the page list data loading method as described above.

[0008] Unlike related technologies, this application constructs a correspondence between the page list, sentinel-observed elements, the target visible area, and the intersection triggering condition, transforming the triggering basis for list data loading from calculation based on scroll position and bottom distance to judgment based on intersection state. Traditional technologies typically require continuous monitoring of scroll events and repeated acquisition of page height, container height, and scroll offset, which can easily lead to judgment errors and runtime overhead in scenarios such as fast scrolling, partially scrolling containers, and dynamic content rendering. This application can determine the loading timing based on the intersection state of sentinel-observed elements relative to the target visible area, reducing reliance on scroll events and position calculation logic, and improving the accuracy of loading triggering and front-end operational stability. Simultaneously, this application controls request sending and observation states through data loading status, pagination information, and data remaining information, reducing the risk of duplicate requests, invalid requests, and state inconsistencies, ensuring good loading continuity, smooth interaction, and convenient code maintenance during continuous browsing of the page list. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having 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.

[0010] Figure 1 This is a schematic diagram of the operating environment for the page list data loading method provided in the embodiments of this application.

[0011] Figure 2 This is a schematic diagram of the execution flow of the page list data loading method provided in the embodiments of this application.

[0012] Figure 3This is a schematic diagram of the execution flow of determining the target visible area and the preset intersection triggering condition in the page list data loading method provided in the embodiments of this application.

[0013] Figure 4 This is a schematic diagram of the execution flow of creating a viewport intersection observation instance in the page list data loading method provided in the embodiments of this application.

[0014] Figure 5 This is a schematic diagram of the system structure of the page list data loading device provided in the embodiments of this application.

[0015] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for executing the page list data loading method provided in this application embodiment. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0017] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0019] To facilitate understanding of this embodiment, a page list data loading method disclosed in this application will first be described in detail. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment for the page list data loading method provided in the embodiments of this application, such as... Figure 1As shown, the execution subject of the page list data loading method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this page list data loading method can be implemented by the processor calling computer-readable instructions stored in the memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded to any number as needed.

[0020] Please continue reading. Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the page list data loading method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Render the page list using the obtained initial list data, and configure the sentinel observation element at the bottom area of ​​the page list according to the list display area of ​​the page list.

[0021] In step S1, the initial list data is the basic data set required for the initial display of the page list, typically including list item content, sorting information, and initial pagination status. After obtaining the initial list data, the page first generates the corresponding list item nodes according to the preset list layout rules and renders the list item nodes to the list display area, allowing users to view existing content on the first screen or within the initial visible range. Configuring a sentinel observation element at the bottom of the page list is to create a boundary node at the end of the list content that can be recognized by subsequent observation mechanisms. This sentinel observation element can typically be represented as a DOM element that does not carry specific business content, primarily serving as a technical marker for the bottom position of the list and a reference for subsequent loading triggers. This approach enables the page list to possess the structural foundation of Lazy Load (where the page doesn't load all content at once, but loads corresponding data or resources only when the user approaches the desired view or when preset trigger conditions are met, reducing the initial load pressure) and Infinite Scroll (where the page automatically requests and appends subsequent list data as the user scrolls down, allowing the user to continuously browse content without manually clicking "next page") from the initial rendering stage, avoiding excessive initial load caused by rendering large amounts of data at once. For example, in a fintech scenario, when the list data volume, such as asset details, transaction records, and message notifications, is large, an initial batch of records can be displayed first, with a sentinel observation element configured at the bottom of the list to provide a trigger for incremental loading during subsequent continuous browsing. In a digital healthcare scenario, content such as examination records, consultation messages, and health record summaries are usually arranged continuously according to time or business type. The page can render the initial data first, and then configure a sentinel observation element at the bottom of the list, allowing subsequent data to continue loading as the user scrolls near the end of the list, thereby improving page initialization speed and continuous browsing experience.

[0022] As an optional implementation, the execution process of step S1 may further include the following sub-steps S11 to S14.

[0023] S11. Based on the data source identifier and initial pagination parameters corresponding to the page list, send an initial data retrieval request to the server and receive the initial list data returned by the server. The initial list data includes list item data and initial pagination status information.

[0024] In step S11, the data source identifier is used to determine the data source or server interface corresponding to the page list, and the initial pagination parameters are used to determine the starting position of the data, the data batch size, or the pagination cursor when the list data is first retrieved. Generating an initial data retrieval request using the data source identifier and initial pagination parameters allows the server to return the corresponding data set according to the initial display requirements of the page list. The list item data in the initial list data is used to generate the list content that can be displayed on the page, and the initial pagination status information is used to record information such as the pagination start point, pagination cursor, current batch status, or whether there is subsequent data, thus providing a state basis for subsequent incremental loading.

[0025] S12. Generate multiple list item nodes based on the list item data, and render the multiple list item nodes in the list display area according to the preset list layout rules.

[0026] In step S12, the list item nodes are page rendering nodes formed by transforming list item data. They can be DOM nodes, virtual nodes, or component nodes in the front-end framework. Preset list layout rules are used to define the arrangement, display order, spacing rules, and content mapping methods of multiple list item nodes in the list display area. By rendering multiple list item nodes according to the preset list layout rules, the initial list data can be displayed with a unified page structure, and subsequent additions of list item nodes can be appended to the page list according to the same layout rules, avoiding inconsistencies between the initial rendering structure and the subsequently appended rendering structure.

[0027] S13. Determine the bottom boundary position of the page list based on the arrangement of multiple list item nodes within the list display area.

[0028] In step S13, the bottom boundary position of the page list refers to the end position of the list content formed after multiple list item nodes are arranged. Since list item nodes may have differences in height, content length, or asynchronous rendering, directly using a fixed position for the observation element may result in the observation position being inconsistent with the actual bottom of the list. Therefore, determining the bottom boundary position based on the arrangement of multiple list item nodes within the list display area ensures that the configuration position of the sentinel observation element corresponds to the actual content boundary of the page list, improving the accuracy of subsequent intersection observations and load trigger judgments.

[0029] S14. Configure a sentinel observation element that does not carry list business content after the bottom boundary position, and generate the pagination information corresponding to the page list according to the initial pagination status information, and establish the loading association relationship between the pagination information and the sentinel observation element.

[0030] In step S14, the sentinel observation element is positioned after the bottom boundary and does not carry list content. This indicates that the element does not participate in the display of specific list information but serves as an observation marker at the end of the list. Based on the initial pagination state information, pagination information corresponding to the page list is generated, converting the pagination state after the initial load into pagination control information that can be continuously used during subsequent loads. After establishing the loading association between pagination information and the sentinel observation element, when the sentinel observation element meets the triggering conditions during subsequent observations, the page list can determine the request parameters for the next batch of data based on the associated pagination information, thus establishing a correspondence between the spatial state of the sentinel observation element and the data loading state of the page list.

[0031] As an example, in a fintech scenario, the page list can be an account transaction list, an asset details list, or a business message list. The page sends an initial data retrieval request to the server based on data source identifiers such as account identifiers and business type identifiers, as well as initial pagination parameters such as initial page number, initial cursor, and single batch data volume. After the server returns the first batch of list item data and initial pagination status information, the front end generates multiple list item nodes based on the list item data and renders them in the list display area according to preset list layout rules such as reverse chronological order, business type grouping, or unified card layout. Then, the bottom boundary position of the page list is determined based on the arrangement of multiple list item nodes. After the bottom boundary position, a sentinel observation element that does not display specific business content is configured, and the initial pagination status information is converted into the pagination information required for subsequent loading of the page list, so that a loading association relationship is formed between the sentinel observation element and the pagination information. In digital healthcare scenarios, page lists can be lists of examination records, consultation messages, or health record summaries. The page retrieves the first batch of medical data based on data source identifiers such as patient-side record identifiers and consultation record type identifiers, as well as initial pagination parameters. It generates corresponding record nodes or message nodes based on the returned list item data and renders them in the list display area according to time order, record type, or session order. Then, the sentinel watch element is configured after the bottom boundary of the current list content, so that the page completes the initial data display while establishing a structural foundation for subsequent loading of historical records or subsequent records based on pagination information.

[0032] Through steps S11 to S14, a correspondence between list data, pagination status, and bottom observation position can be established during the initial display phase of the page list. This ensures that the page list has the structural foundation for subsequent incremental loading after the initial content rendering is completed. This approach helps avoid inconsistencies between the observation element configuration position and the actual list bottom, improving the accuracy of subsequent loading trigger judgments. Furthermore, by associating pagination information with sentinel observation elements, it ensures that subsequent data requests can be continuously executed based on the current list state, thereby enhancing the stability, continuity, and maintainability of the list loading process.

[0033] S2. Based on the target scrolling container information, loading advance information, and intersection ratio threshold corresponding to the page list, determine the target visible area and preset intersection trigger conditions.

[0034] In step S2, the target scrolling container information refers to the information related to the container that carries the scrolling behavior of the page list. The target scrolling container can be a browser window or a partial scrolling area on the page. The loading lead time information refers to the distance range at which data loading is pre-triggered before the sentinel-observed element actually reaches the bottom of the visible area. This information avoids the feeling of waiting caused by the user scrolling to the end of the list before data is requested. The intersection ratio threshold is the proportional standard for triggering judgment when the sentinel-observed element overlaps with the target visible area. This ratio standard improves the controllability of the loading trigger timing. This step determines the actual visible range of the page list through the target scrolling container information, expands the visible range through the loading lead time information, and forms a preset intersection trigger condition through the intersection ratio threshold, so that subsequent loading actions no longer rely on repeated calculations of scroll position, page height, and bottom distance. Taking a fintech scenario as an example, transaction details or asset flow lists need to load the next batch of records in advance during continuous scrolling; the loading lead time can reduce waiting at the bottom of the list. Taking digital healthcare scenarios as an example, examination records or consultation message lists may contain a long history of data. By setting up intersection trigger conditions, subsequent records can be prepared to be loaded before the user approaches the end of the list.

[0035] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow of determining the target visible area and the preset intersection triggering condition in the page list data loading method provided in this application embodiment, as shown below. Figure 3 As shown, the specific steps may include S21 to S24.

[0036] S21. Parse the target scroll container information, determine the target scroll container that carries the page list scrolling behavior, and determine the basic visible area based on the displayable boundary of the target scroll container.

[0037] In step S21, the target scroll container information represents the actual scrolling object of the page list, and may include scroll container identifier, scroll container type, container node information, and container displayable boundary information. Lists on a web page are not always attached to the browser window for scrolling; they may also be located in pop-up areas, card containers, partial scrolling areas, or nested scrolling structures. Traditional list loading schemes, if directly based on window.onscroll (the window scrolling event handling method, i.e., the method that triggers script callbacks when the page window scrolls) or the overall page scroll height, easily overlook the actual scrolling environment of the page list, leading to a mismatch between the loading trigger position and the actual bottom position of the page list. Therefore, by parsing the target scroll container information, the target scroll container carrying the page list scrolling behavior can be determined first, and then the displayable boundary of the target scroll container can be used as a spatial reference to determine the basic visible area. This basic visible area is not simply the screen display range, but a visible judgment range that matches the actual scrolling container of the page list. Therefore, it can provide an accurate spatial basis for viewport judgment in the subsequent IntersectionObserver mechanism (the cross-observer mechanism, i.e., the asynchronous observation interface provided by the browser, used to observe the intersection changes between the target element and the viewport or the specified scrolling container, so as to determine whether the target element enters, leaves or approaches the visible range).

[0038] S22. Based on the loading advance information, expand the bottom boundary of the basic visible area to obtain the target visible area.

[0039] In step S22, the loading lead time information is parameter information for expanding the boundaries of the basic visible area, which can be understood as a buffer range for preloading list data. If only the basic visible area is used as the judgment range, subsequent data loading is usually triggered only after the sentinel-observed element actually enters the user's current visible range. In pages with network latency, slow server response, or high rendering overhead for list items, the user may have already scrolled to the bottom of the list before the new content has finished loading, resulting in waiting or blank areas. Expanding the bottom boundary of the basic visible area according to the loading lead time information yields the target visible area, allowing the sentinel-observed element to enter the judgment range before approaching the actual visible area. This target visible area provides advance trigger space for Lazy Load and Infinite Scroll, enabling subsequent data requests, data returns, and page rendering to begin before the user actually reaches the end of the list, thereby improving the smoothness of continuous scrolling.

[0040] S23. Based on the intersection ratio threshold, construct the intersection ratio judgment condition between the sentinel's observed elements and the target's visible area.

[0041] In step S23, the intersection ratio threshold is a quantitative condition that measures the degree of overlap between the sentinel-observed element and the target visible area. This threshold can be used to determine whether the proportion of the sentinel-observed element entering the target visible area meets the triggering standard. Traditional solutions based on scroll events (scroll events, i.e., events triggered when a document or element scrolls) typically require a combination of parameters such as scrollbar position, container height, content height, and bottom distance to determine whether to load subsequent data. This method is easily affected by changes in container size, list item height, asynchronous image loading, and page reflow. By constructing an intersection ratio judgment condition through the intersection ratio threshold, the loading trigger can be transformed from complex position difference calculations into a judgment of the intersection relationship between the sentinel-observed element and the target visible area. This avoids premature loading triggering when the sentinel-observed element is just approaching the target visible area, and also avoids frequent loading judgments when the intersection changes little, making the loading triggering timing more stable and controllable.

[0042] S24. Based on the target's visible area and the intersection ratio, generate preset intersection trigger conditions.

[0043] In step S24, the target visible area defines the spatial range for intersection judgment, and the intersection ratio judgment condition defines the degree of intersection that the sentinel-observed elements need to achieve. Together, they form the preset intersection trigger condition. This preset intersection trigger condition essentially transforms the criterion for "when to load subsequent data" from traditional scroll position calculation to a state judgment based on the target visible area and intersection ratio. Subsequent viewport intersection observation instances can use this condition to determine whether the sentinel-observed element has entered a triggerable loading state, thereby reducing the frequent calculations of getBoundingClientRect (the method for obtaining the element's boundary rectangle, i.e., the method for obtaining the element's position, width, and height relative to the viewport), scroll height, and bottom distance during continuous scrolling by the user. This approach is more in line with the technical mechanism of the IntersectionObserver API (the browser interface used to create intersection observation instances and trigger callback processing based on changes in the visible ratio between the target element and the root observation area), which can reduce the computational pressure on the main thread, improve the accuracy of loading trigger judgment under complex page structures, and enhance the adaptability and stability of the page list under different scroll containers, different terminal sizes, and different rendering states. In the original technical documentation, the solution in this case achieves pull-up loading by monitoring the changes in the intersection between the sentinel element at the bottom of the list and the viewport. Therefore, this set of steps is a core innovative element.

[0044] As an example, in a fintech scenario, the page list can be an asset details list, a transaction record list, or a business message list. The page can first determine the target scrolling container based on the page structure where the list is located, such as a browser window, a card-style scrolling area, or a scrolling area within a pop-up window, and determine the basic visible area based on the displayable boundary of the target scrolling container. Then, according to the preset loading lead time information, the bottom boundary of the basic visible area is expanded so that the sentinel observation element at the bottom of the list enters the target visible area before it actually enters the user's visible range. Then, based on the intersection ratio threshold, the intersection ratio judgment condition between the sentinel observation element and the target visible area is constructed so that IntersectionObserver can trigger subsequent judgments when the sentinel observation element reaches the specified intersection ratio (intersection ratio, i.e., the proportion of the currently visible part of the target element to the total area of ​​the target element). In digital healthcare scenarios, page lists can be lists of examination records, consultation messages, or health record summaries. The page can determine the basic visible area based on the scrolling container corresponding to the record display area, and reserve data request and page rendering time by loading advance information. Then, it limits the extent to which sentinel-observed elements enter the target visible area by using an intersection ratio threshold, thereby generating preset intersection trigger conditions suitable for Lazy Load or InfiniteScroll, enabling the page to more stably determine the timing of subsequent data loading during continuous user browsing.

[0045] Through steps S21 to S24, the triggering judgment for subsequent data loading in the list can be transformed from traditional scroll position calculation to state judgment based on the target visible range and intersection ratio, ensuring that the loading triggering conditions match the actual scrolling environment of the page list. This approach can adapt to different page structures such as browser windows, partial scroll containers, and nested scroll areas, reducing false or missed triggers caused by inconsistent container boundaries. Simultaneously, by creating a pre-loading buffer range through loading lead time, subsequent data loading can be initiated before the user reaches the bottom of the list, reducing the feeling of waiting and the risk of blank display. Limiting the entry degree of the sentinel-observed element by using an intersection ratio threshold improves the stability of triggering timing and reduces unnecessary repeated judgments during frequent scrolling. Therefore, this approach helps reduce the front-end's dependence on scroll events, scroll height, and bottom distance, improving the accuracy, continuity, and page stability of loading triggering in Infinite Scroll scenarios.

[0046] S3. Configure observation parameters according to the target visible area and preset intersection trigger conditions, and create a viewport intersection observation instance based on the observation parameters and preset intersection state callback logic.

[0047] In step S3, the observation parameters are the configuration basis required to create a viewport intersection observation instance. These parameters can include the visible range parameter corresponding to the target visible area, the trigger range parameter corresponding to the loading lead, and the proportion threshold parameter corresponding to the intersection proportion threshold. The preset intersection state callback logic refers to the callback processing logic executed when the intersection state between the sentinel observed element and the target visible area changes. This logic can read the intersection state and provide a data basis for subsequent trigger judgments. This step creates a viewport intersection observation instance by configuring the observation parameters and callback logic, enabling the page to utilize the browser's native Intersection Observer mechanism to manage the visibility changes of elements at the bottom of the list without continuously listening to scroll events and frequently performing position calculations. For example, in a fintech scenario, when a user quickly views message notifications or fund change records, the viewport intersection observation instance can identify the approaching state of the bottom of the list at the browser level, reducing page script execution overhead. In a digital healthcare scenario, health record summaries or follow-up record pages may contain images, text, and timeline information; the viewport intersection observation instance created based on the observation parameters can adapt to the continuous loading requirements under complex page layouts.

[0048] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow of creating a viewport intersection observation instance in the page list data loading method provided in this application embodiment, as shown below. Figure 4 As shown, the specific steps may include S31 to S35.

[0049] S31. Analyze the visible area of ​​the target to obtain the container identifier, displayable boundary information, and boundary extension information corresponding to the target scrolling container.

[0050] In step S31, the target visible area is the observation range formed after the aforementioned basic visible area is expanded by loading advance. Parsing the target visible area allows for further decomposition of the container identifier, displayable boundary information, and boundary expansion information corresponding to the target scrolling container. The container identifier is used to determine the scrolling container object actually referenced by the viewport intersection observation instance; the displayable boundary information characterizes the boundary range of the page content that the target scrolling container can currently display; and the boundary expansion information characterizes the preload buffer range added outside the basic displayable boundary. By decomposing the above information, subsequent observation parameter configuration can have a clear data source, avoiding judgment bias in local scrolling container scenarios caused by directly using the entire page window as a unified observation range.

[0051] S32. Generate visible range parameters based on container identifier and displayable boundary information, and generate trigger range parameters based on boundary extension information and preset intersection trigger conditions.

[0052] In step S32, the visible range parameter is generated based on the container identifier and displayable boundary information. It is used to limit the spatial range referenced when the viewport intersection observation instance performs intersection judgment. In the web front-end implementation, this type of parameter can correspond to the observation root region in the IntersectionObserver mechanism, such as the scroll container range represented by the root (observation root, i.e., the viewport or scroll container used as the reference for intersection judgment). The trigger range parameter is generated based on boundary expansion information and preset intersection trigger conditions. It mainly represents the spatial boundary that can be judged in advance when the sentinel observation element approaches the target visible area. In specific implementations, it can correspond to boundary expansion logic similar to rootMargin (root margin, i.e., the parameter that expands or shrinks the boundary of the observation root region before performing intersection judgment, used to trigger intersection judgment in advance or delay). By generating the visible range parameter and the trigger range parameter respectively, the "observation range" and the "early trigger range" can be distinguished, so that the observation instance can accurately match the scroll container where the page list is located, while reserving request and rendering time for subsequent data loading.

[0053] S33. Extract the intersection ratio judgment condition from the preset intersection trigger condition, and generate the ratio threshold parameter according to the intersection ratio judgment condition.

[0054] In step S33, the intersection ratio judgment condition is a quantification judgment part of the preset intersection trigger condition, used to limit the required degree of overlap between the sentinel observed element and the target visible area. Generating a ratio threshold parameter based on the intersection ratio judgment condition allows the viewport intersection observation instance to consider not only whether the sentinel observed element enters the target visible area, but also whether the proportion of its entry into the target visible area meets the set standard when judging whether the sentinel observed element meets the loading trigger state. In specific implementations, this ratio threshold parameter can correspond to the threshold configuration concept in IntersectionObserver (intersection threshold, i.e., the parameter that triggers a callback judgment when the intersection ratio between the target element and the observed root area reaches a specified value). Using the ratio threshold parameter, false triggers caused when the sentinel observed element only slightly touches the target visible area can be reduced, and repeated loading judgments can be avoided when the position change is small, improving the stability of the triggering timing.

[0055] S34. Configure the observation parameters according to the visible range parameter, trigger range parameter, and proportional threshold parameter.

[0056] In step S34, the observation parameters are comprehensive configuration parameters used when creating a viewport intersection observation instance, consisting of visible range parameters, trigger range parameters, and proportional threshold parameters. The visible range parameter limits the observation reference object, the trigger range parameter limits the pre-triggered boundary, and the proportional threshold parameter limits the intersection degree standard. By configuring the observation parameters according to these parameters, the viewport intersection observation instance can operate according to the actual scroll container where the page list is located, the preload buffer range, and the intersection ratio standard after creation. Compared to the traditional method of continuously calculating scroll distance through scroll events, this parameterized configuration method can transform complex scroll position judgments into browser-manageable intersection observation conditions, thereby reducing the continuous calculation pressure on the front-end script.

[0057] S35. Bind the observation parameters and the preset intersection state callback logic, create a viewport intersection observation instance, and initialize the observation enable state corresponding to the viewport intersection observation instance and the data loading state corresponding to the page list.

[0058] In step S35, the preset intersection state callback logic is the processing logic executed by the viewport intersection observation instance after detecting a change in the intersection between the sentinel observation element and the target's visible area. Binding the observation parameters and the preset intersection state callback logic allows the viewport intersection observation instance to have both a clear observation range and triggering criteria, as well as the ability to handle states after intersection changes. After creating the viewport intersection observation instance, initializing the observation enable state clarifies whether the instance is currently allowed to observe the sentinel observation element. Initializing the data loading state corresponding to the page list clarifies whether the page list is currently allowed to send new list data loading requests. By simultaneously initializing the observation enable state and the data loading state, a state foundation is provided for subsequent sentinel observation element registration, intersection state acquisition, and loading request control, avoiding problems such as repeated observation, repeated triggering, or unclear request states immediately after the observation instance is created.

[0059] As an example, in a fintech scenario, the page list can be an asset transaction list, a transaction details list, or a business message list. After determining the target visible area, the page can parse the container identifier, displayable boundary information, and boundary extension information of the corresponding scrolling container. For example, when the list is located in a local scrolling area of ​​the account details page, this local scrolling area can be used as the observation reference object of IntersectionObserver. The visible range parameter is generated based on the displayable boundary of the scrolling area, the trigger range parameter is generated based on the preload buffer distance, and the ratio threshold parameter is generated based on the intersection ratio judgment condition. This allows the sentinel to observe elements and trigger subsequent loading judgments when the set intersection ratio is reached. In digital healthcare scenarios, page lists can be lists of examination records, consultation messages, or health record summaries. When the list is located in a patient details page, a record pop-up, or a mobile partial scrolling container, the container identifier and boundary information can be obtained by parsing the target visible area. The visible range parameter, trigger range parameter, and proportional threshold parameter are configured as observation parameters. The observation parameters are then bound to the preset intersection state callback logic to create a viewport intersection observation instance. At the same time, the observation enable state and data loading state are initialized, enabling the page to stably identify the intersection changes of sentinel observation elements in Lazy Load or Infinite Scroll scenarios, and providing a state basis for subsequent data loading request control.

[0060] Through steps S31 to S35, the target visible area, trigger boundary, and intersection ratio standard can be converted into observation parameters recognizable by the viewport intersection observation instance. This allows the observation instance to perform intersection judgment according to the actual scroll container and preload range of the page list. This processing method avoids the problem of inaccurate observation range under different scroll containers, different page layouts, or different terminal display ranges, while improving the stability of trigger judgment through the ratio threshold parameter. After the observation parameters are bound to the preset intersection state callback logic, a unified state processing basis can be formed when the intersection of the sentinel observed elements changes. By initializing the observation enable state and data loading state, the risk of repeated observation, repeated triggering, and request state confusion is reduced, thereby improving the loading trigger accuracy, operational stability, and code maintenance convenience of the page list in Lazy Load and Infinite Scroll scenarios.

[0061] S4. Observe the sentry observation element through the viewport intersection observation instance to obtain the intersection state information of the sentry observation element relative to the target's visible area.

[0062] In step S4, the sentinel observation element is an observation object configured in the bottom area of ​​the page list. This element itself does not carry list business content but serves as a technical marker at the end of the list. After the viewport intersection observation instance observes the sentinel observation element, it can generate intersection change records when the sentinel observation element enters, leaves, or approaches the target visible area. The intersection state information can include element boundary information, area boundary information, intersection area information, intersection ratio information, and intersection identifier information, which can reflect the spatial relationship between the sentinel observation element and the target visible area. This step provides an objective basis for subsequent judgment on whether to trigger data loading by collecting intersection state information. Taking the fintech scenario as an example, when a user browses the transaction record list and approaches the bottom of the current batch of records, the change in the intersection ratio of the sentinel observation element can indicate that the user is about to view subsequent records. Taking the digital healthcare scenario as an example, when a user continuously views historical test results or consultation dialogues, the intersection state of the sentinel observation element relative to the target visible area can serve as a trigger for subsequent data loading.

[0063] As an optional implementation, the execution process of step S4 above may further include the following sub-steps S41 to S45.

[0064] S41. When the viewport intersection observation instance is in the observation enabled state, the registered sentinel observation element is the observation object of the viewport intersection observation instance.

[0065] In step S41, the observation enable state indicates whether the viewport intersection observation instance currently has the conditions to perform the observation task. When the viewport intersection observation instance is in the observation enable state, the sentinel observation element is registered as the observation object of the viewport intersection observation instance, enabling the browser to include the sentinel observation element at the bottom of the page list within the observation range of IntersectionObserver. Through this process, changes in the positional relationship between the sentinel observation element and the target visible area can be continuously identified, providing a basis for subsequently obtaining intersection change records.

[0066] S42. When the positional relationship between the sentinel's observed element and the target's visible area changes, the intersection change record is obtained through the preset intersection state callback logic.

[0067] In step S42, the change in the positional relationship between the sentinel-observed element and the target visible area refers to changes in the degree of the sentinel-observed element's entry, departure, approach, or overlap relative to the target visible area during page scrolling. When the above positional relationship changes, the preset intersection state callback logic can obtain the corresponding intersection change record. The intersection change record can be understood as the observation result data formed by IntersectionObserver after detecting a change in the visibility of the target element. This record can reflect the spatial state of the sentinel-observed element relative to the target visible area at the current moment.

[0068] S43. Extract the element boundary information of the sentry observation element, the area boundary information of the target's visible area, the intersection area information, and the intersection ratio information from the intersection change record.

[0069] In step S43, the element boundary information is used to characterize the boundary range of the sentinel-observed element on the page, the region boundary information is used to characterize the boundary range of the target's visible area, the intersection region information is used to characterize the area where the sentinel-observed element and the target's visible area overlap, and the intersection ratio information is used to characterize the proportional relationship between the overlapping area and the sentinel-observed element or the target's visible area. By extracting the above information from the intersection change record, abstract positional changes can be converted into calculable and judgeable state data, avoiding reliance on scroll distance and list bottom distance for manual calculation.

[0070] S44. Generate intersection status information based on element boundary information, region boundary information, intersection region information, and intersection ratio information.

[0071] In step S44, the intersection state information is a judgment criterion formed by comprehensively organizing element boundary information, region boundary information, intersection region information, and intersection ratio information. The intersection state information characterizes whether the sentinel observes an element entering the target's visible area, the degree to which it enters the target's visible area, and whether the current intersection state has the potential to trigger subsequent data loading. By generating intersection state information, subsequent trigger judgments can have a clear data basis, improving the stability and consistency of the judgment process.

[0072] S45. Send the intersection status information to the trigger condition judgment process to determine whether the intersection status information meets the preset intersection trigger condition.

[0073] In step S45, the trigger condition judgment process is used to determine whether the intersection state information meets the preset intersection trigger condition. After sending the intersection state information to the trigger condition judgment process, the current intersection ratio, intersection area, and boundary relationship of the sentinel observed elements can be matched with the preset intersection trigger condition to determine whether to enter the subsequent data loading process. This processing method enables the list loading triggering process to be based on the browser's native intersection observation results, reducing the reliance on scroll events and frequent position calculation logic such as getBoundingClientRect, and improving the accuracy and operational stability of loading trigger judgment in Infinite Scroll scenarios. The solution in the original technical document also revolved around triggering data loading by listening to the intersection changes between the sentinel element at the bottom of the list and the viewport through IntersectionObserver.

[0074] As an example, in a fintech scenario, the page list can be a transaction details list, an asset flow list, or a business message list. When the viewport intersection observation instance is in the observation enabled state, the page registers the sentinel observation element at the bottom of the list as the observation object, enabling IntersectionObserver to continuously identify the positional changes between the sentinel observation element and the target visible area. When the user continuously swipes through transaction records or message notifications, the sentinel observation element gradually approaches or enters the target visible area. The preset intersection state callback logic obtains the corresponding intersection change records and extracts element boundary information, area boundary information, intersection area information, and intersection ratio information from them to form intersection state information that can represent the current intersection ratio, thereby determining whether the preset intersection triggering conditions are met. In digital healthcare scenarios, the page list can be a list of examination records, a list of consultation messages, or a list of health record summaries. As users continue to browse the history, the sentinel observation element at the bottom of the page changes position as the list scrolls. The viewport intersection observation instance generates intersection status information based on the intersection change record and sends the intersection status information to the trigger condition judgment process, so that the page can determine whether to continue loading subsequent medical records or historical consultation content based on the degree to which the sentinel observation element enters the target visible area.

[0075] Through steps S41 to S45, the sentinel-observed element can be included in the observation range of the viewport intersection observation instance. When the positional relationship between the sentinel-observed element and the target visible area changes, intersection state information that can be used to trigger the judgment is formed. This processing method allows the data loading judgment of the page list to be based on objective state data such as element boundaries, area boundaries, intersection areas, and intersection ratios, avoiding reliance on continuous calculations of scroll distance, page height, and list bottom distance. By sending the intersection state information to the trigger condition judgment process, subsequent loading requests can be executed only when the preset intersection trigger conditions are met, thereby improving the accuracy and stability of pull-to-load triggering, reducing false triggers, missed triggers, and duplicate judgments in fast scrolling scenarios, and reducing the runtime overhead of the page frontend.

[0076] S5. When the intersection status information meets the preset intersection triggering conditions, according to the data loading status and pagination information of the page list, send a list data loading request to the server and receive the newly added list data returned by the server.

[0077] In step S5, the data loading status indicates whether the page list is currently in a state where a loading request can be sent. The pagination information indicates the page number, cursor, batch identifier, or whether subsequent data still exists in the current list. When the intersection status information meets the preset intersection trigger condition, the page does not directly and unconditionally send a request. Instead, it further judges the data loading status and pagination information to avoid repeatedly sending list data loading requests before the previous request is completed, and to avoid continuing to request the server when there is no subsequent data. This step controls the timing of request sending through intersection trigger judgment, loading status judgment, and pagination judgment, making the list data loading process more stable. For example, in a fintech scenario, asset details or transaction records may trigger the bottom approach state multiple times when the user scrolls quickly; the data loading status can prevent repeated requests for the same batch of data within a short period. In a digital healthcare scenario, historical data such as consultation messages or examination records are usually returned in pages; the pagination information can accurately determine whether it is necessary to continue requesting earlier or subsequent batches of data.

[0078] As an optional implementation, the execution process of step S5 may further include the following sub-steps S51 to S54.

[0079] S51. When the intersection status information meets the preset intersection triggering conditions, obtain the data loading status and pagination information corresponding to the page list.

[0080] In step S51, if the intersection status information meets the preset intersection triggering condition, it indicates that the sentinel-observed element has entered a state where subsequent data loading can be triggered. Further obtaining the data loading status and pagination information corresponding to the page list at this point is to confirm whether the current page has the conditions to continue loading before sending the request. The data loading status indicates whether the page list is currently executing a data request, while the pagination information indicates the data batch, pagination cursor, page number information, or subsequent data existence status of the current list data. By simultaneously reading the data loading status and pagination information, it is possible to avoid directly triggering a request based solely on the sentinel-observed element entering the target's visible area, thereby improving the accuracy of loading control.

[0081] S52. When the data loading status is idle and the pagination information indicates that there is subsequent list data, generate a list data loading request based on the pagination information and update the data loading status to loading status.

[0082] In step S52, the idle state indicates that the page list is not currently in the process of requesting data, while the pagination information indicates that there is subsequent list data, meaning the page has the conditions to continue requesting the next batch of data. Generating a list data loading request based on the pagination information allows the server to return the corresponding subsequent data based on the current pagination cursor, page number, or batch identifier. Updating the data loading status to "loading" locks the page list's state after the request is sent, preventing sentinel-observed elements from repeatedly triggering the same data loading request due to position changes, page bounces, or continuous scrolling. This approach reduces the risk of duplicate requests and rendering, improving data loading stability in Infinite Scroll scenarios.

[0083] S53. Send a list data loading request to the server and receive the newly added list data returned by the server based on the list data loading request.

[0084] In step S53, the list data loading request is used to request subsequent data for the page list from the server. This request can carry request parameters such as pagination information, data source identifier, batch data volume, or filtering conditions. The server determines the range of data to be returned based on the list data loading request and returns the newly added list data. This newly added list data typically includes newly added list items, but may also include updated pagination status or data remaining status. By receiving the newly added list data returned by the server, the page can append subsequent data without reloading the entire list content, thereby reducing front-end rendering pressure and network transmission pressure.

[0085] S54. When the data loading status is "loading", or the pagination information indicates that there is no subsequent list data, stop sending list data loading requests.

[0086] In step S54, when the data loading status is "loading," it indicates that there are still unfinished data requests in the page list. At this point, sending new list data loading requests is stopped to avoid data duplication, disordered order, or state overwriting caused by concurrent requests. When the pagination information indicates that there is no more list data to load, it means that the server has no more list content to load. At this point, sending list data loading requests is stopped to prevent invalid requests from consuming network and server processing resources. This approach uses the loading and pagination statuses to jointly constrain request sending behavior, enabling the subsequent data loading process to prevent duplicate triggering and terminate when there is no data, thereby improving the reliability and resource utilization efficiency of the page list loading process.

[0087] As an example, in a fintech scenario, the page list can be a transaction log list, an asset details list, or a business message list. When the intersection status information of the elements observed by the sentinel meets the preset intersection trigger conditions, the page further obtains the current data loading status and pagination information. If the data loading status is idle and the pagination information indicates that there are still subsequent records, a list data loading request is generated based on the current page number, pagination cursor, or batch identifier, and the data loading status is updated to loading status to avoid repeated requests for the same batch of transaction records or message data during rapid scrolling. Subsequently, the list data loading request is sent to the server, and the newly added list data returned by the server is received for subsequent appending and rendering to the page list. When the data loading status is already loading status, or the pagination information indicates that there is no subsequent list data, the page stops sending new list data loading requests, thereby reducing duplicate loading and invalid requests. In digital healthcare scenarios, the page list can be a list of examination records, a list of consultation messages, or a list of health record summaries. When a user continuously browses to near the end of the current data batch, the page triggers a loading judgment based on the intersection status information. It then determines whether to continue requesting subsequent records based on the data loading status and pagination information. If the data is not currently loading and there are still subsequent medical records, a list data loading request with pagination information is sent to the server, and the newly added list data is received. If a request is already being executed or subsequent records have already been loaded, the request is stopped to avoid duplicate loading, disordered order, or invalid access to historical consultation content, examination records, or health record data.

[0088] Through steps S51 to S54, after the intersection state meets the triggering condition, the request sending can be further constrained by combining the data loading state and pagination information. This ensures that list data loading is not simply executed based on the visible state of elements observed by the sentinel, but rather a request is sent only when it is confirmed that the page list is in a loadable state and that subsequent data still exists. This approach effectively reduces duplicate requests caused by rapid scrolling, page bounces, or repeated changes in the intersection state, preventing the same batch of list data from being loaded or appended multiple times. Furthermore, by updating the data loading state to "loading" before sending the request, a request locking mechanism can be established, ensuring that no new loading requests are initiated before the previous loading process is completed. Stopping the request sending when the pagination information indicates that there is no subsequent list data also reduces invalid network access and server resource consumption. Therefore, this approach helps improve the request accuracy, state consistency, and data loading stability during the page list pull-up loading process.

[0089] S6. Update the page list based on the newly added list data, and update the observation status of the sentinel observation elements based on the data balance information corresponding to the newly added list data.

[0090] In step S6, the newly added list data is the subsequent data set returned by the server based on the list data loading request. This typically includes newly added list item data, updated pagination information, and data availability information. After receiving the newly added list data, the page can convert it into new list item nodes and append it to existing list item nodes, thus maintaining the user's continuous page structure. Updated pagination information synchronizes the current data batch status of the page list. After the data loading state returns to idle, the page can continue processing the next eligible loading trigger. Data availability information is used to determine if the server still has subsequent list data. When subsequent list data exists, the sentinel observation element remains in the observation enabled state; when no subsequent list data exists, the observation of the sentinel observation element can be stopped and updated to the observation ended state. For example, in a fintech scenario, after adding transaction records, the page can decide whether to continue enabling Infinite Scroll based on whether there are still subsequent transaction records. In a digital healthcare scenario, after adding health records or consultation records, the page can determine whether to retain the bottom loading trigger capability based on data availability information, thus avoiding repeated requests when there is no data.

[0091] As an optional implementation, the execution process of step S6 may further include the following sub-steps S61 to S65.

[0092] S61. Parse the newly added list data to obtain the data of the newly added list items, the pagination information after the update, and the data remaining information.

[0093] In step S61, the newly added list data is the subsequent data set returned by the server based on the list data loading request. By parsing the newly added list data, the content returned by the server can be broken down into newly added list item data, updated pagination information, and data remaining information. The newly added list item data corresponds to the list content that needs to be appended and displayed, the updated pagination information corresponds to the pagination status after this loading is completed, and the data remaining information corresponds to whether the server still has subsequent list data. This parsing process can convert the server's returned results into the data foundation required for subsequent updates of the page list, maintenance of pagination status, and control of the sentinel observation status.

[0094] S62. Generate new list item nodes based on the new list item data, and append the new list item nodes to the existing list item nodes in the page list.

[0095] In step S62, the newly added list item node is a page display node generated based on the data of the newly added list item. It can be a DOM node, a virtual node, or a front-end component node. After appending the newly added list item node to the existing list item node, the list can be expanded without re-rendering all list content, maintaining a continuous display structure for the page list. This approach reduces the overhead of repeated rendering, avoids the loss of page scroll position or interruption of user browsing due to a full refresh, and allows newly added content in Infinite Scroll scenarios to seamlessly follow existing content.

[0096] S63. Update the pagination information corresponding to the page list according to the updated pagination information, and update the data loading status of the page list to idle state.

[0097] In step S63, the updated pagination information reflects the pagination position, pagination cursor, current batch status, or subsequent data status after the newly added data has been loaded. Updating the pagination information corresponding to the page list based on the updated pagination information ensures that the next list data loading request can be generated based on the latest pagination status, avoiding duplicate requests for already loaded data or skipping unloaded data. Simultaneously, updating the data loading status of the page list to an idle state indicates that the current request and data appending process has been completed, and the page list is once again ready to receive the next loading trigger, thus forming a closed-loop control of the data loading status.

[0098] S64. When the data reserve information indicates that there is subsequent list data, keep the observation status of the sentinel observation element in the observation enabled state.

[0099] In step S64, the remaining data information indicates that the server still holds unloaded list content if subsequent list data exists. Maintaining the sentinel observation element's observation state in this case allows the viewport intersection observation instance to continue observing the sentinel observation element. When the user continues browsing and the sentinel observation element again meets the preset intersection trigger condition, the page list can continue into the subsequent data loading process. This approach ensures continuous list loading capability, enabling the page to continuously complete incremental loading in multi-batch data scenarios.

[0100] S65. When the data margin information indicates that there is no subsequent list data, stop observing the sentinel observation element through the viewport intersection observation instance, and update the observation state of the sentinel observation element to the observation end state.

[0101] In step S65, when the remaining data information indicates that there is no more list data, it means that the page list has completed displaying all loadable data. At this point, stopping the observation of the sentinel observation element through the viewport intersection observation instance and updating the observation state of the sentinel observation element to the observation-completed state prevents the sentinel observation element from generating invalid intersection judgments and invalid loading triggers at the bottom of the list. This approach reduces unnecessary observation callbacks and network request risks, while clearly indicating that the page list has entered the loading-completed state, improving resource utilization efficiency and state consistency during the list loading process.

[0102] As an example, in a fintech scenario, the page list can be a transaction log list, an asset details list, or a business message list. After the server returns the newly added list data based on the list data loading request, the page can parse the new transaction record, the updated pagination cursor, and the remaining data information. It then generates a corresponding list item node based on the new transaction record and appends this node to the existing transaction record node, allowing the user to continue viewing subsequent data from their current position. The page then updates the pagination information synchronously based on the updated pagination cursor and restores the data loading state to an idle state. If the remaining data information indicates that there are still subsequent transaction records or message data, the sentinel observation element remains in the observation enabled state so that loading checks can continue to be triggered during subsequent scrolling. If the remaining data information indicates that there is no subsequent data, the viewport intersection observation instance stops observing the sentinel observation element, and the sentinel observation element is updated to the observation ended state. In digital healthcare scenarios, page lists can be lists of examination records, consultation messages, or health record summaries. The page can convert new examination records, historical consultation content, or health record summaries returned by the server into new list item nodes and append them to existing record nodes, while simultaneously updating pagination information and data loading status. When the remaining data information indicates that there are still subsequent medical records, the page continues to maintain the sentinel observation element's monitoring state. Once all records have been loaded, the page stops monitoring the sentinel observation element, thus avoiding invalid loading judgments when there is no subsequent data.

[0103] Through steps S61 to S65, the process of appending list content, updating pagination status, restoring loading status, and controlling sentinel observation status can be completed after receiving new list data, forming a complete closed loop in the page list data loading process. This approach, without reloading all list content, continuously appends new list items to existing list items, reducing page rendering overhead and maintaining the stability of the list structure during continuous browsing. Simultaneously, by updating pagination information and restoring the data loading status, the next loading request is guaranteed to be based on the latest data state, reducing issues such as duplicate loading, missed loading, or pagination status errors. When subsequent list data still exists, the sentinel observation element remains active, supporting continuous incremental loading of the page list. When no further list data exists, observation of the sentinel observation element is stopped and updated to the observation end state, reducing invalid observation callbacks and invalid loading requests. Therefore, this approach improves the stability, state consistency, and front-end resource utilization efficiency of continuous page list loading.

[0104] The page list data loading method provided in this application associates the bottom position of the page list, the target visible area, the intersection trigger condition, and the data loading state, transforming the trigger judgment for subsequent data loading from traditional scroll position calculation to state judgment based on changes in element visibility. This method reduces the frequent calculation of scroll height, bottom distance, and element position during continuous page scrolling, lowers front-end runtime overhead, and improves trigger accuracy in complex page structures, partial scrolling containers, and different terminal display environments. Simultaneously, by controlling the loading timing through loading lead time and intersection ratio thresholds, subsequent data loading can be initiated before the user approaches the bottom of the list, reducing the feeling of waiting and the risk of blank display. Through the coordinated control of data loading state, pagination information, and data remaining information, duplicate requests, invalid requests, and pagination state errors can also be avoided, ensuring that the page list maintains good loading continuity, state consistency, and interaction stability during continuous browsing.

[0105] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the page list data loading device provided in the embodiments of this application, such as... Figure 5 As shown, the page list data loading device 50 includes: an initial rendering configuration module 51, a trigger condition determination module 52, an observation instance creation module 53, an intersection state acquisition module 54, a loading request sending module 55, and a list state update module 56.

[0106] The initial rendering configuration module 51 is specifically used to render the page list using the acquired initial list data, and configure sentinel observation elements in the bottom area of ​​the page list according to the list display area of ​​the page list; the trigger condition determination module 52 is specifically used to determine the target visible area and preset intersection trigger conditions according to the target scroll container information, loading advance information and intersection ratio threshold corresponding to the page list; the observation instance creation module 53 is specifically used to configure observation parameters according to the target visible area and the preset intersection trigger conditions, and create viewport intersection observation instances based on the observation parameters and preset intersection state callback logic; the intersection state acquisition module 5... Specifically, the 4 module is used to observe the sentinel observation element through the viewport intersection observation instance and obtain the intersection status information of the sentinel observation element relative to the target visible area; the loading request sending module 55 is specifically used to send a list data loading request to the server according to the data loading status and pagination information corresponding to the page list when the intersection status information meets the preset intersection triggering condition, and receive the newly added list data returned by the server; the list status update module 56 is specifically used to update the page list according to the newly added list data, and update the observation status of the sentinel observation element according to the data remaining information corresponding to the newly added list data.

[0107] As an optional implementation, the initial rendering configuration module 51 is specifically used to send an initial data acquisition request to the server according to the data source identifier and initial pagination parameters corresponding to the page list, and receive the initial list data returned by the server, the initial list data including list item data and initial pagination status information; generate multiple list item nodes according to the list item data, and render the multiple list item nodes in the list display area according to a preset list layout rule; determine the bottom boundary position of the page list according to the arrangement result of the multiple list item nodes in the list display area; configure a sentinel observation element that does not carry list business content after the bottom boundary position, and generate pagination information corresponding to the page list according to the initial pagination status information, and establish a loading association relationship between the pagination information and the sentinel observation element.

[0108] As an optional implementation, the trigger condition determination module 52 is specifically used to parse the target scroll container information, determine the target scroll container that carries the page list scrolling behavior, and determine the basic visible area based on the displayable boundary of the target scroll container; expand the bottom boundary of the basic visible area according to the loading advance information to obtain the target visible area; construct the intersection ratio judgment condition between the sentinel observation element and the target visible area based on the intersection ratio threshold; and generate the preset intersection trigger condition according to the target visible area and the intersection ratio judgment condition.

[0109] As an optional implementation, the observation instance creation module 53 is specifically used to parse the target visible area to obtain the container identifier, displayable boundary information, and boundary extension information corresponding to the target scrolling container; generate a visible range parameter based on the container identifier and the displayable boundary information, and generate a trigger range parameter based on the boundary extension information and the preset intersection trigger condition; extract an intersection ratio judgment condition from the preset intersection trigger condition, and generate a ratio threshold parameter based on the intersection ratio judgment condition; configure the observation parameters according to the visible range parameter, the trigger range parameter, and the ratio threshold parameter; bind the observation parameters and the preset intersection state callback logic to create the viewport intersection observation instance, and initialize the observation enable state corresponding to the viewport intersection observation instance and the data loading state corresponding to the page list.

[0110] As an optional implementation, the intersection state acquisition module 54 is specifically used to register the sentinel observation element as the observation object of the viewport intersection observation instance when the viewport intersection observation instance is in the observation enabled state; when the positional relationship between the sentinel observation element and the target visible area changes, the module acquires the intersection change record through the preset intersection state callback logic; extracts the element boundary information of the sentinel observation element, the area boundary information of the target visible area, the intersection area information, and the intersection ratio information from the intersection change record; generates the intersection state information based on the element boundary information, the area boundary information, the intersection area information, and the intersection ratio information; and sends the intersection state information to the trigger condition judgment process to determine whether the intersection state information meets the preset intersection trigger condition.

[0111] As an optional implementation, the loading request sending module 55 is specifically used to: obtain the data loading status and pagination information corresponding to the page list when the intersection status information meets the preset intersection triggering condition; generate a list data loading request based on the pagination information when the data loading status is idle and the pagination information indicates that there is subsequent list data, and update the data loading status to loading status; send the list data loading request to the server and receive the newly added list data returned by the server based on the list data loading request; and stop sending the list data loading request when the data loading status is loading status or the pagination information indicates that there is no subsequent list data.

[0112] As an optional implementation, the list state update module 56 is specifically used to parse the newly added list data to obtain the newly added list item data, updated pagination information, and data remaining information; generate a new list item node based on the newly added list item data, and append the new list item node to the existing list item nodes of the page list; update the pagination information corresponding to the page list based on the updated pagination information, and update the data loading status of the page list to an idle state; when the data remaining information indicates that there is subsequent list data, keep the observation status of the sentinel observation element in the observation enabled state; when the data remaining information indicates that there is no subsequent list data, stop observing the sentinel observation element through the viewport intersection observation instance, and update the observation status of the sentinel observation element to the observation ended state.

[0113] It should be noted that the above-described page list data loading device can execute the page list data loading method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the page list data loading device embodiments can be found in the page list data loading method provided in the embodiments of this application.

[0114] Figure 6 This is a schematic diagram of the hardware structure of the electronic device for executing the page list data loading method provided in the embodiments of this application, as shown below. Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0115] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0116] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the page list data loading method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the page list data loading method in the above-described method embodiments.

[0117] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the page list data loading device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and these remote memories may be connected to the page list data loading device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0118] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the page list data loading method in any of the above method embodiments, for example, performing the above-described... Figure 2 Method steps S1 to S6, Figure 3 Method steps S21 to S24, Figure 4Steps S31 to S35 in the method are implemented. Figure 5 The functions of modules 51-56 in the document.

[0119] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0120] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 can enable the one or more processors to execute the page list data loading method in any of the above method embodiments, for example, to execute the above-described... Figure 2 Method steps S1 to S6, Figure 3 Method steps S21 to S24, Figure 4 Steps S31 to S35 in the method are implemented. Figure 5 The functions of modules 51-56 in the document.

[0121] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions that, when executed by the electronic device, enable the electronic device to perform the page list data loading method in any of the above method embodiments, for example, to perform the above-described method. Figure 2 Method steps S1 to S6, Figure 3 Method steps S21 to S24, Figure 4 Steps S31 to S35 of the method are implemented. Figure 5 The functions of modules 51-56 in the document.

[0122] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0124] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for loading page list data, characterized in that, include: Render the page list using the acquired initial list data, and configure a sentinel observation element in the bottom area of ​​the page list according to the list display area of ​​the page list; Based on the target scrolling container information, loading advance information and intersection ratio threshold corresponding to the page list, determine the target visible area and preset intersection trigger conditions; Configure observation parameters according to the target visible area and the preset intersection triggering condition, and create a viewport intersection observation instance based on the observation parameters and the preset intersection state callback logic; The sentinel observation element is observed through the viewport intersection observation instance to obtain the intersection state information of the sentinel observation element relative to the target's visible area; When the intersection status information meets the preset intersection triggering condition, according to the data loading status and pagination information corresponding to the page list, a list data loading request is sent to the server, and the newly added list data returned by the server is received. The page list is updated based on the newly added list data, and the observation status of the sentinel observation element is updated based on the data surplus information corresponding to the newly added list data.

2. The page list data loading method according to claim 1, characterized in that, The step of rendering a page list using the acquired initial list data, and configuring a sentinel observation element at the bottom area of ​​the page list according to the list display area of ​​the page list, includes: Based on the data source identifier and initial pagination parameters corresponding to the page list, an initial data retrieval request is sent to the server, and the initial list data returned by the server is received. The initial list data includes list item data and initial pagination status information. Multiple list item nodes are generated based on the list item data, and the multiple list item nodes are rendered in the list display area according to the preset list layout rules; The bottom boundary position of the page list is determined based on the arrangement of the multiple list item nodes within the list display area. After the bottom boundary position, configure a sentinel observation element that does not carry list business content, and generate pagination information corresponding to the page list according to the initial pagination status information, and establish a loading association relationship between the pagination information and the sentinel observation element.

3. The page list data loading method according to claim 1, characterized in that, The step of determining the target visible area and preset intersection triggering conditions based on the target scrolling container information, loading advance information, and intersection ratio threshold corresponding to the page list includes: The target scroll container information is parsed to determine the target scroll container that carries the page list scrolling behavior, and the basic visible area is determined based on the displayable boundary of the target scroll container; Based on the loading advance information, the bottom boundary of the basic visible area is expanded to obtain the target visible area; Based on the intersection ratio threshold, construct the intersection ratio judgment condition between the sentinel observation element and the target visible area; Based on the target visible area and the intersection ratio judgment condition, the preset intersection trigger condition is generated.

4. The page list data loading method according to claim 1, characterized in that, The step of configuring observation parameters based on the target visible area and the preset intersection triggering condition, and creating a viewport intersection observation instance based on the observation parameters and the preset intersection state callback logic, includes: The target visible area is analyzed to obtain the container identifier, displayable boundary information, and boundary extension information corresponding to the target scrolling container; A visible range parameter is generated based on the container identifier and the displayable boundary information, and a trigger range parameter is generated based on the boundary extension information and the preset intersection trigger condition; Extract the intersection ratio judgment condition from the preset intersection trigger condition, and generate the ratio threshold parameter based on the intersection ratio judgment condition; Configure the observation parameters according to the visible range parameters, the trigger range parameters, and the proportional threshold parameters; Bind the observation parameters and the preset intersection state callback logic to create the viewport intersection observation instance, and initialize the observation enable state corresponding to the viewport intersection observation instance and the data loading state corresponding to the page list.

5. The page list data loading method according to claim 1, characterized in that, The step of observing the sentry observation element through the viewport intersection observation instance and obtaining the intersection state information of the sentry observation element relative to the target's visible area includes: When the viewport intersection observation instance is in the observation enabled state, the sentinel observation element is registered as the observation object of the viewport intersection observation instance; When the positional relationship between the sentinel observation element and the target visible area changes, the intersection change record is obtained through the preset intersection state callback logic; Extract the element boundary information of the sentinel's observed element, the area boundary information of the target's visible area, the intersection area information, and the intersection ratio information from the intersection change record; The intersection state information is generated based on the element boundary information, the region boundary information, the intersection region information, and the intersection ratio information; The intersection status information is sent to the trigger condition judgment process to determine whether the intersection status information meets the preset intersection trigger condition.

6. The page list data loading method according to claim 1, characterized in that, When the intersection status information satisfies the preset intersection trigger condition, a list data loading request is sent to the server according to the data loading status and pagination information corresponding to the page list, and the newly added list data returned by the server is received, including: When the intersection status information meets the preset intersection triggering condition, the data loading status and pagination information corresponding to the page list are obtained; When the data loading status is idle and the pagination information indicates that there is subsequent list data, a list data loading request is generated based on the pagination information, and the data loading status is updated to loading status. Send the list data loading request to the server and receive the newly added list data returned by the server according to the list data loading request; When the data loading status is "loading", or the pagination information indicates that there is no subsequent list data, the list data loading request is stopped.

7. The page list data loading method according to claim 1, characterized in that, The step of updating the page list based on the newly added list data and updating the observation status of the sentinel observation element based on the data reserve information corresponding to the newly added list data includes: Parse the newly added list data to obtain the newly added list item data, the updated pagination information, and the remaining data information; A new list item node is generated based on the newly added list item data, and the new list item node is appended and rendered after the existing list item nodes in the page list; Update the pagination information corresponding to the page list according to the updated pagination information, and update the data loading status of the page list to idle status; When the data reserve information indicates that there is subsequent list data, the observation status of the sentinel observation element is kept in the observation enabled state; When the data margin information indicates that there is no subsequent list data, stop observing the sentinel observation element through the viewport intersection observation instance, and update the observation status of the sentinel observation element to the observation end status.

8. A page list data loading device, characterized in that, include: The initial rendering configuration module is used to render the page list based on the acquired initial list data, and to configure sentinel observation elements in the bottom area of ​​the page list according to the list display area of ​​the page list. The trigger condition determination module is used to determine the target visible area and preset intersection trigger conditions based on the target scroll container information, loading advance information and intersection ratio threshold corresponding to the page list; The observation instance creation module is used to configure observation parameters according to the target visible area and the preset intersection triggering conditions, and to create viewport intersection observation instances based on the observation parameters and the preset intersection state callback logic. The intersection state acquisition module is used to observe the sentinel observation element through the viewport intersection observation instance and acquire the intersection state information of the sentinel observation element relative to the target visible area; The loading request sending module is used to send a list data loading request to the server according to the data loading status and pagination information corresponding to the page list when the intersection status information meets the preset intersection triggering condition, and to receive the newly added list data returned by the server. The list status update module is used to update the page list according to the newly added list data, and to update the observation status of the sentinel observation element according to the data balance information corresponding to the newly added list data.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the page list data loading method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the page list data loading method according to any one of claims 1-7.

Images