Display method of interface and related device

Abstract

The application provides a display method of an interface and related devices. The method comprises: providing a display interface; the display interface comprises a first dynamic component and a second dynamic component; in the case that the first dynamic component receives a trigger operation, generating a first change request and sending the first change request to a server; the first change request comprises first state change data; in the case that the second dynamic component receives a trigger operation, generating a second change request and sending the second change request to the server; the second change request comprises second state change data; in the case that the second dynamic component receives a trigger operation and no response data corresponding to the first change request is received, the second change request further comprises the first state change data. The display method of the interface and the related devices can improve the response speed of the dynamic component in the interface to a certain extent and improve the user experience.

Description

Technical Field

[0001] One or more embodiments of this application relate to the field of e-commerce technology, and in particular to a method for displaying an interface and related apparatus. Background Technology

[0002] In related technologies, in high-frequency interaction scenarios such as internet healthcare and e-commerce, pages typically contain multiple independently operable dynamic components (such as disease selection components and patient information components on prescription consultation pages, or delivery method components and coupon components on checkout pages).

[0003] After a dynamic component is triggered, it sends a state change request to the server and changes its state upon receiving the server's response. In some cases, multiple dynamic components may be triggered consecutively. In this case, the client will wait sequentially for the response data of the previous state change request before initiating the next state change request.

[0004] However, the related technologies suffer from lag in dynamic component changes, which reduces the user experience. Summary of the Invention

[0005] In view of this, one or more embodiments of this application provide a method and related apparatus for displaying an interface, which can improve the response speed of dynamic components in the interface to a certain extent and enhance the user experience.

[0006] In a first aspect, one or more embodiments of this application propose a method for displaying an interface, comprising: providing a display interface; wherein the display interface includes a first dynamic component and a second dynamic component; when the first dynamic component receives a trigger operation, generating a first change request and sending the first change request to a server; wherein the first change request includes first state change data; the first state change data is used to characterize a state change that the first dynamic component needs to perform; when the second dynamic component receives a trigger operation, generating a second change request and sending the second change request to the server; wherein the second change request includes second state change data; the second state change data is used to characterize a state change that the second dynamic component needs to perform; wherein, when the second dynamic component receives a trigger operation but has not yet received response data corresponding to the first change request, the second change request further includes the first state change data.

[0007] Secondly, one or more embodiments of this application propose a method for displaying an interface, comprising: receiving in parallel a first change request and a second change request from a client; wherein the first change request includes first state change data; the first state change data is used to characterize a state change that the first dynamic component needs to perform; the second change request includes the first state change data and the second state change data; the second state change data is used to characterize a state change that the second dynamic component needs to perform; asynchronously responding to the first change request and the second change request, generating response data corresponding to the first change request and generating response data corresponding to the second change request; wherein the response data of the first change request includes display data corresponding to the first state change data; the response data of the second change request includes display data corresponding to the first state change data and display data corresponding to the second state change data; asynchronously sending the response data of the first change request and the response data of the second change request to the client.

[0008] Thirdly, one or more embodiments of this application provide a computer device including a memory and a processor, wherein the memory stores at least one computer program, which is loaded and executed by the processor to implement the method as described above.

[0009] Fourthly, one or more embodiments of this application provide a computer program product characterized by including computer instructions that, when executed by a processor, implement the method as described above.

[0010] As can be seen from the above embodiments, in the multiple embodiments provided in this application, by setting a first dynamic component and a second dynamic component in the display interface, and generating a first change request when the first dynamic component receives a trigger operation, and generating a second change request when the second dynamic component receives a trigger operation, the state changes of each dynamic component can be independently reported to the server in the form of a request. Furthermore, when the second dynamic component receives a trigger operation and the previous change request has not yet received response data, the state change data of the previous change request is merged into the subsequent change request. This allows the server to obtain multiple incomplete state change data at once and process them uniformly once it has processed a change request that includes multiple state change data during asynchronous processing of multiple change requests. This reduces the response lag of dynamic components in the interface and improves the user experience in scenarios where multiple dynamic components are continuously operated or frequently interacted. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a module of an interface display system provided in one embodiment of this specification.

[0012] Figure 2 This is a schematic diagram illustrating the interaction between a client and a server, provided as a scenario example in this manual.

[0013] Figure 3 This is a flowchart of an interface display method provided in one embodiment of this specification.

[0014] Figure 4a and 4b This is a schematic diagram of a task queue provided in one embodiment of this specification.

[0015] Figure 5 This is a flowchart of an interface display method provided in one embodiment of this specification.

[0016] Figure 6 This is a schematic diagram of a client module provided in one embodiment of this specification.

[0017] Figure 7 This is a schematic diagram of a server module provided in one embodiment of this specification.

[0018] Figure 8 This is a schematic diagram of a computer device provided in one embodiment of this description. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0020] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0022] In related technologies, in high-frequency interaction scenarios such as internet healthcare and e-commerce, pages are often composed of multiple independently operable dynamic components, such as disease selection components and medication user information components in prescription consultation pages, or delivery method components and coupon components in e-commerce checkout pages.

[0023] When a dynamic component receives a user-triggered action, it generates a state change request and sends it to the server. The component then updates its display state only after the server returns a response. While this approach ensures consistency between the component's state and the server's, when multiple dynamic components are triggered consecutively by the user, subsequent requests typically require waiting for the previous request to complete. This results in a sequential waiting process, leading to sluggish UI feedback and a degraded user experience.

[0024] Therefore, it is necessary to propose a new technical solution that can improve the response speed of dynamic components in the interface, so as to enhance the user experience.

[0025] Please see Figure 1 In several embodiments provided in this application, the interface display method can be applied to an interface display system with certain computing power and network access capabilities. The interface display system may include a client and a server. The client may be a user terminal device such as a desktop computer, laptop computer, tablet computer, or smartphone, or it may be an application interface deployed locally. The server may be a server with high computing power and data processing capabilities, used to centrally process change requests from multiple clients.

[0026] Specifically, the client includes a processor, a memory, and a network access module for network communication. The processor generates a first change request and a second change request in the display interface, and merges the first state change data into the second change request when the second dynamic component receives a trigger operation and the first change request has not yet returned. The memory stores the state information of the first and second dynamic components in the display interface, as well as the generated change request data. The network access module sends the change request to the server and receives the response data returned by the server.

[0027] The server includes a processor and a memory. The processor receives and parses first and second change requests from the client. When a request includes multiple state change data, it can process the state changes of multiple dynamic components simultaneously and return corresponding response data. The memory stores the state change data uploaded by the client and the processed response data. Through collaboration between the client and server, the response latency of dynamic components in the interface can be reduced in high-frequency interaction scenarios, improving the user experience.

[0028] One embodiment of this application also provides a custom communication protocol for interaction between a client and a server. The components involved in the custom communication protocol can be divided into the following component types: blocks, component sets, and leaf components.

[0029] A block can be a container used to divide the overall display interface. A block can contain a collection of components and / or leaf components. Furthermore, a block itself does not contain specific display data, and the visibility of the block can be controlled by the values ​​of its fields. A component collection represents a set of components, including at least one leaf component. A component collection itself does not contain specific display data, and the visibility of the entire collection can be controlled by the values ​​of its fields. Leaf components contain specific data and event information. Leaf components can be rendered and displayed in the display interface.

[0030] The custom communication protocol comprises several components, including page hierarchy, component transaction data, and page snapshots. The page hierarchy definition describes the component hierarchy of the displayed interface. Specifically, the fields included in the page hierarchy are shown in Table 1 below.

[0031] Table 1 In the page hierarchy, we define that blocks can contain component collections and / or leaf components, while component collections can only contain leaf components. The hierarchical relationship is represented using a key-value pair, where the key is the component identifier and the value is a list of lower-level component identifiers. This allows us to express the overall layout of the displayed interface.

[0032] Component transaction data can include the transaction data of each component. Specifically, the fields included in component transaction data are shown in Table 2 below.

[0033] Table 2 A page snapshot can be a snapshot of the displayed interface. Specifically, in several embodiments of this specification, a page snapshot can refer to interface component state representation data. This interface component state representation data is used to characterize the component composition and component state of the displayed interface.

[0034] Please see Figure 1 and Figure 2One embodiment of this application provides an example application scenario for a method of displaying an interface. This method can be applied to an interface display system. Specifically, the client is responsible for rendering the display interface, and the server is responsible for parsing and processing change requests from the client. The display interface may include blocks, component collections, and leaf components. Leaf components can be divided into dynamic components and static components. Dynamic components can generate state change requests based on user operations, while static components maintain fixed displayed content. For example, a dynamic component may be the smallest indivisible interactive unit, such as a single button, input box, or checkbox, which can directly carry user operations. Static components may be text controls such as titles or descriptive text.

[0035] For example, suppose a user initiates a UI access request to the server via the client, receives UI data from the server, renders it, and then provides the user with a prescription consultation page related to a medical scenario. This page, as a display interface, includes a first dynamic component and a second dynamic component. The first dynamic component could be a disease selection component, allowing the user to select diseases such as "hypertension" or "diabetes" as diagnostic references. The second dynamic component could be a patient information component, used to fill in the patient's name, age, and past medical history. During initial loading, the client sends a UI access request to the server, and the server returns UI data and UI component state representation data. The UI data includes the two dynamic components mentioned above and their initial transaction data. The UI component state representation data serves as a page snapshot, representing the component composition and state of the interface in its initial state; for example, the disease selection component is in "unselected," and the patient information component is in "blank."

[0036] In this application scenario, when a user selects "Hypertension" in the disease selection component, the client generates a first change request, carrying first state change data. This data indicates that the disease selection component has switched from "Not Selected" to "Hypertension Selected." The client sends the first change request to the server and adds it to the task queue to mark it as pending. If, before the server returns the response data for the first change request, the user enters "Zhang San, 45 years old" in the medication user information component, the second dynamic component receives a trigger operation, and the client generates a second change request. Since the first change request has not yet received a response, the client merges the first state change data into the second change request, so that the second change request contains both the first and second state change data. Subsequently, the client adds the second change request to the task queue so that the interface can be updated uniformly after the server completes processing.

[0037] Furthermore, a user might enter the patient's name in the medication information component before receiving response data from the disease selection component. At this point, the second dynamic component receives a trigger operation, and the client generates a second change request. This second change request contains second state change data, representing the state change that the medication information component needs to perform. Simultaneously, since the first change request has not yet completed its response, the client merges the first state change data into the second change request, making the request carry both first and second state change data. When the server receives this second change request, it restores the current display interface data based on the interface component state representation data included in the request. Then, it processes the first state change data of the disease selection component and the second state change data of the medication information component in sequence, generating the corresponding display data, which is returned to the client in the second response data. Upon receiving this second response data, the client can update the display effects of multiple dynamic components at once and remove the overwritten first change request from the task queue, thus ensuring that the interface display state remains consistent with the user's actions.

[0038] In another scenario, such as an e-commerce checkout page, users select a coupon immediately after switching delivery methods. The delivery method component, as the first dynamic component, uses its state change data to represent the switch from "standard express" to "express delivery." The coupon component, as the second dynamic component, uses its state change data to represent the coupon selection. When the client generates a second change request, it includes not only the coupon's state change data but also the delivery method's state change data, for which no response has yet been received. The server, through a mechanism of parallel reception and asynchronous response, can process both the first and second change requests simultaneously, restoring the displayed interface data based on the state representation data of each component and generating corresponding response data. When the client receives the response data for the second change request, it can update the display effects of both the delivery method and coupon components at once, thereby reducing waiting time and improving user experience.

[0039] In this example scenario, by introducing task queues, request identifiers, and UI component state representation data into the interaction between the client and server, it is possible to ensure that in high-frequency scenarios where multiple dynamic components are continuously operated on, the server can accurately restore the UI state and complete the updates of multiple dynamic components at once. The client, relying on the management mechanism of task queues and request identifiers, can effectively avoid repeatedly processing overwritten requests and ensure the consistency of UI display under asynchronous responses. Thus, the UI display method of this application can reduce the response latency of dynamic components, improve the real-time performance and interactive smoothness of the display interface in internet healthcare and e-commerce scenarios, thereby significantly improving the user experience.

[0040] Please see Figure 3One embodiment of this application provides a method for displaying an interface. This method can be applied to an interface display system, specifically to a client within that system. The method may include the following steps.

[0041] Step S110: Provide a display interface; wherein the display interface includes a first dynamic component and a second dynamic component.

[0042] Step S120: When the first dynamic component receives a trigger operation, it generates a first change request and sends the first change request to the server; wherein, the first change request includes first state change data; the first state change data is used to characterize the state change that the first dynamic component needs to perform.

[0043] Step S130: When the second dynamic component receives a trigger operation, it generates a second change request and sends the second change request to the server; wherein, the second change request includes second state change data; the second state change data is used to characterize the state change that the second dynamic component needs to perform; wherein, when the second dynamic component receives a trigger operation but has not yet received response data corresponding to the first change request, the second change request also includes the first state change data.

[0044] In this embodiment, the client provides a display interface, which may include a first dynamic component and a second dynamic component. A dynamic component refers to an interface element whose state changes according to user-triggered actions. Examples include a disease selection component and a patient information component on a prescription consultation page, or a delivery method component and a coupon component on a checkout page.

[0045] In this embodiment, when the first dynamic component receives a user-triggered operation, the client generates a first change request. The first change request is a structured data request carrying first state change data. This first state change data characterizes the state change that the first dynamic component needs to perform. For example, it could be switching the checkmark state, updating input information, or adjusting the component's visibility state. The client sends the first change request to the server so that the server can process the state change.

[0046] In this embodiment, when the second dynamic component receives a user-triggered operation, the client generates a second change request. The second change request carries second state change data, representing the state change that the second dynamic component needs to perform. For example, selecting a coupon or switching delivery methods. Under normal circumstances, the second change request can be sent independently to the server.

[0047] In some cases, when the second dynamic component receives a trigger operation, if the client has not yet received the response data for the first change request, the client will merge the first state change data into the second change request when generating the second change request. This ensures that the second change request contains both the first and second state change data simultaneously. In this way, the server, upon receiving the second change request, can learn about the state change requirements of both the first and second dynamic components at once, even if the first change request has not yet been processed, thus reducing UI lag caused by sequential request execution.

[0048] In this embodiment, the server can receive a first change request and a second change request from the client, and parse the state change data carried in the requests. If the second change request includes both the first and second state change data, the server can uniformly update the states of multiple dynamic components in a single response to the second change request and generate corresponding response data. The response data returned by the server will be used to update the state of the corresponding components in the client's display interface, thereby ensuring the consistency between the interface display result and the user's operational intent.

[0049] In some implementations, change requests can be implemented based on a custom communication protocol, and state change data can be carried in the component transaction data section. In some implementations, response data for corresponding change requests issued by the server can be implemented based on a custom communication protocol, and display data corresponding to the state change data can be carried in the component transaction data section.

[0050] In this embodiment of the application, when the second dynamic component is triggered and the first change request has not yet returned response data, the client can upload the first state change data and the second state change data together through the second change request. This enables the server to reduce the response lag of dynamic components in the interface and improve the user experience in the scenario of asynchronously processing change requests.

[0051] Please see Figure 4a and Figure 4b In some implementations, the client can add the first change request to a task queue, and remove the first change request from the task queue upon receiving response data corresponding to the first change request; if the second dynamic component receives a trigger operation but does not receive response data corresponding to the first change request, it generates a second change request including the first state change data and the second state change data, and adds the second change request to the task queue.

[0052] In this implementation, the client can set up a task queue. A task queue is a data structure used to cache and manage pending change requests. Task queues can improve the controllability of multiple change requests during asynchronous interaction.

[0053] In this embodiment, when the first dynamic component receives a trigger operation and generates a first change request, the client adds the first change request to the task queue to mark the request as being in a processing state awaiting response data from the server. When the client receives the response data corresponding to the first change request, it removes the first change request from the task queue, thereby keeping only requests that have not yet been processed in the task queue.

[0054] In some cases, when the second dynamic component receives a trigger operation, if the client has not yet received the response data for the first change request, the client will generate a second change request that includes both the first and second state change data. In this case, the second change request simultaneously represents the state change requirements of both the first and second dynamic components, allowing the server to complete multiple state changes within a single request processing flow. Subsequently, the client can add the second change request to a task queue to maintain consistency of the request state while waiting for the server to return response data.

[0055] In this implementation, the client utilizes a task queue to manage incomplete change requests in a unified manner. This allows change requests from multiple dynamic components to be merged, cached, and removed as needed when they are triggered consecutively. This not only avoids UI interaction delays caused by sequential waiting for change requests but also maintains accurate consistency between the displayed UI state and the user's intended operation even when the server returns a partial response.

[0056] In some implementations, if the client receives response data corresponding to the second change request but does not receive response data corresponding to the first change request, it can update the display interface based on the second response data and remove the first change request from the task queue; wherein, the second response data includes display data corresponding to the first state change data and display data corresponding to the second state change data.

[0057] In this embodiment, upon receiving response data corresponding to the second change request, the client can directly update the display interface based on the response data. The second response data is structured data returned by the server, used to indicate the target display state of each dynamic component in the display interface. Specifically, the second response data may simultaneously include display data corresponding to the first state change data and display data corresponding to the second state change data, thereby ensuring that the states of multiple dynamic components can be synchronously updated during a single interaction.

[0058] In some cases, when the client receives the second response data, it may not have yet received the response data corresponding to the first change request. In this case, the client updates the interface display related to the first and second dynamic components based on the second response data, and removes the corresponding first change request from the task queue, thereby avoiding duplicate processing of state change requirements that have already been covered by the second response data.

[0059] In this embodiment, the client can update the displayed interface promptly using the response data of the second change request even without receiving the response data of the first change request, while maintaining consistency between the request status in the task queue and the interface display status. This not only reduces display delays caused by waiting for the response of the previous request, but also ensures that the user interface promptly presents the latest status in high-frequency interaction scenarios, thereby further improving the user experience.

[0060] In some implementations, the client may have request identifiers for both the first change request and the second change request; wherein the response data corresponding to the first change request carries the request identifier of the first change request, and the response data corresponding to the second change request carries the request identifier of the second change request.

[0061] In this implementation, the client can assign request identifiers to the first change request and the second change request respectively. A request identifier is a data field used to uniquely identify a change request and to establish a correspondence between requests and responses during the interaction between the task queue and the server.

[0062] Under normal circumstances, when the server returns response data corresponding to the first change request, it will include the request identifier of the first change request in the response data; similarly, when the server returns response data corresponding to the second change request, it will include the request identifier of the second change request in the response data. After receiving the response data, the client can confirm the change request corresponding to the response data based on the request identifier contained in the response data.

[0063] Furthermore, in the task queue, when the client receives a response data, it can remove the change request corresponding to that request identifier, along with any previously uncompleted change requests, from the task queue based on the request identifier carried in the response data. This ensures that the task queue only retains pending change requests that have not yet been covered by response data, thereby avoiding redundant processing or repeated updates to the component states in the interface.

[0064] In this implementation, the client can manage the correspondence between change requests and response data in the task queue based on request identifiers. In high-frequency interaction scenarios, even if multiple dynamic components trigger and generate multiple change requests consecutively, the client can quickly clear overwritten change requests in the task queue based on the request identifier when receiving any response data. This ensures that the display state of components in the interface is consistent with the user's operation intention, while reducing unnecessary waiting and processing overhead, further improving the real-time performance and smoothness of the interface interaction.

[0065] In some implementations, the first change request and the second change request each further include interface component state representation data of the display interface; wherein, the interface component state representation data is used to represent the component composition and component state of the display interface; the interface component state representation data is used by the server to restore the interface data corresponding to the display interface based on the interface component state representation data, adjust the interface data according to the first state change data and / or the second state change data, regenerate the interface component state representation data representing the adjusted interface data, and put the interface component state representation data of the adjusted interface data into the response data of the first change request and the response data of the second change request.

[0066] In this embodiment, when generating the first and second change requests, the client can attach interface component state representation data to the change requests. Interface component state representation data is a snapshot of the page that represents the overall state of the displayed interface at a certain moment, reflecting the component composition and state of the displayed interface. Specifically, the interface component state representation data can include the hierarchical structure, attribute information, and current display state of each dynamic component in the interface. By introducing interface component state representation data, the server can completely reconstruct the displayed interface data at the time the client initiated the request based on this snapshot data when receiving the change request.

[0067] In this embodiment, when the server receives the first change request, it can restore the corresponding display interface data based on the interface component state representation data, and adjust the state of the first dynamic component based on the first state change data. After completing the adjustment, the server will regenerate the interface component state representation data corresponding to the adjusted interface data and return this interface component state representation data as part of the response data for the first change request to the client. After receiving the response data for the first change request, the client can use the adjusted interface component state representation data contained therein to update the display interface, ensuring that the state of the dynamic components in the interface is consistent with the server's processing result.

[0068] In another scenario, when the server receives a second change request, it may contain both first and second state change data. The server can first restore the displayed interface data based on the UI component state representation data included in the second change request, and then adjust the states of the first and second dynamic components sequentially based on the first and second state change data. Subsequently, the server will regenerate the adjusted UI component state representation data and include it in the response data of the second change request, returning it to the client. Upon receiving the response data of the second change request, the client can directly use this adjusted UI component state representation data to update the displayed interface, thus achieving simultaneous refreshing of the states of multiple dynamic components at once.

[0069] In this implementation, by transmitting UI component state representation data in the change request and response data, it is possible to ensure the consistency of the dynamic component states in the interface between the server and the client in high-frequency interaction scenarios. Even if there are multiple consecutive change requests, the client and server can rely on the UI component state representation data as a unified page snapshot for state restoration and updates, avoiding abnormal interface display caused by out-of-order processing of change requests or loss of state, thereby further improving the user's interactive experience.

[0070] Please see Figure 5 This application also provides a method for displaying an interface. This method can be applied to a server. The method may include the following steps.

[0071] Step S210: Receive a first change request and a second change request from the client in parallel; wherein, the first change request includes first state change data; the first state change data is used to characterize the state change that the first dynamic component needs to perform; the second change request includes the first state change data and the second state change data; the second state change data is used to characterize the state change that the second dynamic component needs to perform.

[0072] Step S220: Asynchronously respond to the first change request and the second change request, generate response data corresponding to the first change request, and generate response data corresponding to the second change request; wherein, the response data for the first change request includes display data corresponding to the first state change data; the response data for the second change request includes display data corresponding to the first state change data and display data corresponding to the second state change data.

[0073] Step S230: Asynchronously send the response data of the first change request and the response data of the second change request to the client.

[0074] In this embodiment, the server can receive a first change request and a second change request from the client in parallel. The first change request is a structured data request, which includes first state change data to characterize the state changes that the first dynamic component needs to perform. The second change request may include the first state change data, as well as second state change data to characterize the state changes that the second dynamic component needs to perform. By receiving these requests in parallel, the server can avoid forcibly sequentially processing multiple change requests when they arrive almost simultaneously, thereby improving processing concurrency.

[0075] In this embodiment, after receiving the first change request and the second change request, the server can process them separately using an asynchronous response mechanism. Specifically, when parsing the first change request, the server generates corresponding first response data based on the state change data contained therein. The first response data may include display data related to the first state change data to guide the client to update the first dynamic component. When parsing the second change request, the server can generate corresponding second response data based on both the first and second state change data contained therein. The second response data includes display data for updating the first and second dynamic components, ensuring that multiple dynamic components are updated synchronously in a single response.

[0076] In this embodiment, after generating the first and second response data, the server can asynchronously send them to the client. Asynchronous sending means that the server does not need to wait for the completion of a response to a change request before pushing the generated response data to the client. This ensures that the client receives feedback from the server more quickly in high-frequency interaction scenarios and updates the displayed interface promptly.

[0077] In this implementation, by implementing parallel reception and asynchronous response to change requests on the server side, processing delays caused by sequential waiting of requests can be avoided. When the second change request is responded to first before the first change request is processed, the second response data generated by the server already contains both the first and second state change data, allowing the client to rely on the second response data to complete a full update of the interface. This ensures that even if the first response data arrives later, it will not affect the correctness of the client interface. Therefore, under the mechanism of multi-request concurrency and asynchronous response, the response latency of dynamic components can be significantly reduced while maintaining interface consistency.

[0078] In some implementations, the server may receive a UI access request from the client; obtain UI data corresponding to the UI access request and UI component state representation data corresponding to the UI data; the UI data includes a first dynamic component and a second dynamic component; wherein the UI component state representation data is used to represent the component composition and component state of the UI data; and send response data corresponding to the UI access request to the client; wherein the response data for the UI access request includes the UI data and the UI component state representation data.

[0079] In this embodiment, the server can be used to receive interface access requests from the client. An interface access request is a request sent by the client when initializing or refreshing the display interface, used to obtain complete interface data and its corresponding status information from the server, so as to ensure that the client can present an interface effect consistent with the server.

[0080] In this embodiment, after receiving a UI access request, the server can retrieve the corresponding UI data and the corresponding UI component state representation data from storage. Using the UI component state representation data, the server can accurately describe the complete UI state that the client needs to reconstruct during the initial access.

[0081] In this embodiment, after obtaining the interface data and the interface component state representation data, the server can package them into response data and return it to the client. This response data includes both the interface data and the interface component state representation data. Upon receiving this response data, the client can load the basic component layout of the display interface based on the interface data and synchronize the state of each component using the interface component state representation data, enabling the display interface to completely reproduce the logical state maintained by the server.

[0082] In this implementation, by returning interface data and interface component state representation data in the response data of the interface access request, the client can quickly restore the interface to the target state defined by the server when initializing or reloading the interface. This not only ensures the integrity and consistency of the interface during the first load or refresh, but also provides a unified state benchmark for subsequent first and second change requests, thereby improving the overall stability of the interaction and the user experience.

[0083] In some implementations, the first change request and the second change request each carry interface component state characterization data; the interface component state characterization data respectively characterizes the component composition and component state of the corresponding display interface when the client issues the first change request or the second change request; the server can, upon receiving the first change request, restore the interface data of the corresponding display interface according to the interface component state characterization data carried in the first change request, adjust the component state of the first dynamic component based on the first state change data, generate the adjusted display data of the first dynamic component, and send the adjusted display data of the first dynamic component to the client; upon receiving the second change request, restore the interface data of the corresponding display interface according to the interface component state characterization data carried in the second change request, adjust the component state of the first dynamic component based on the first state change data, generate the adjusted display data of the first dynamic component, and adjust the component state of the second dynamic component based on the second state change data, generate the adjusted display data of the second dynamic component, and send the adjusted display data of the first dynamic component and the adjusted display data of the second dynamic component to the client.

[0084] In this embodiment, the first change request and the second change request can each carry interface component state representation data. This interface component state representation data is used to characterize the component composition and state of the interface displayed by the client when it issues the change request. It serves as a type of page snapshot data, providing a basis for the server to accurately recreate the interface state at the time the request is triggered.

[0085] In this embodiment, when the server receives a first change request, it can restore the corresponding display interface data based on the interface component state representation data carried in the first change request. After restoring the display interface data, the server adjusts the component state of the first dynamic component based on the first state change data in the first change request and generates display data corresponding to the adjustment result. Subsequently, the server returns this display data as part of the response data for the first change request to the client, so that the client can update the content related to the first dynamic component in the display interface, thereby ensuring that the state of the dynamic component in the interface is consistent with the server's processing result.

[0086] In some cases, when the server receives a second change request, it can also restore the corresponding display interface data based on the UI component state representation data carried in the second change request. Based on this, the server first adjusts the component state of the first dynamic component according to the first state change data, generating the adjusted display data for the first dynamic component; then, it adjusts the component state of the second dynamic component according to the second state change data, generating the adjusted display data for the second dynamic component. Finally, the server merges the display data of the two dynamic components and returns it to the client as part of the response data for the second change request, enabling the client to complete the synchronous update of multiple dynamic components at once.

[0087] In this embodiment, by carrying interface component state representation data in the first and second change requests, the server can accurately restore the display interface data at the time the client sends the request, even when asynchronously processing multiple change requests. Furthermore, it provides display interface data corresponding to the adjusted interface state when generating response data. Thus, even if multiple dynamic components are triggered consecutively, the client can still quickly refresh the display interface based on the response data returned by the server, ensuring that the dynamic component states of the interface remain consistent with the user's operational intentions, thereby further reducing display lag and improving the interactive experience.

[0088] Please see Figure 6 The embodiments of this application also provide a client. The client includes: a providing module, a first request generation module, and a second request generation module.

[0089] A module is provided for providing a display interface; wherein the display interface includes a first dynamic component and a second dynamic component.

[0090] The first request generation module is configured to generate a first change request and send the first change request to the server when the first dynamic component receives a trigger operation; wherein the first change request includes first state change data; the first state change data is used to characterize the state change that the first dynamic component needs to perform.

[0091] The second request generation module is configured to generate a second change request and send the second change request to the server when the second dynamic component receives a trigger operation; wherein the second change request includes second state change data; the second state change data is used to characterize the state change that the second dynamic component needs to perform; wherein, when the second dynamic component receives a trigger operation but has not yet received response data corresponding to the first change request, the second change request also includes the first state change data.

[0092] In this embodiment, the functions and effects implemented by the client can be explained in comparison with the aforementioned embodiments, and will not be repeated here.

[0093] Please see Figure 7 The embodiments of this application also provide a server. The server includes: a receiving module, a response module, and a sending module.

[0094] The receiving module is used to receive a first change request and a second change request sent by the client in parallel; wherein, the first change request includes first state change data; the first state change data is used to characterize the state change that the first dynamic component needs to perform; the second change request includes the first state change data and the second state change data; the second state change data is used to characterize the state change that the second dynamic component needs to perform.

[0095] The response module is used to asynchronously respond to the first change request and the second change request, generate response data corresponding to the first change request, and generate response data corresponding to the second change request; wherein, the response data for the first change request includes display data corresponding to the first state change data; the response data for the second change request includes display data corresponding to the first state change data and display data corresponding to the second state change data.

[0096] The sending module is used to asynchronously send the response data of the first change request and the response data of the second change request to the client.

[0097] In this embodiment, the functions and effects implemented by the server can be explained in comparison with the aforementioned embodiments, and will not be repeated here.

[0098] Please see Figure 8 This application also provides a computer device comprising: a memory and a processor, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the method described above.

[0099] The memory, processor, and communication interface in the computer device can communicate with each other via the system bus and network communication.

[0100] In this embodiment, the functions and effects implemented by the computer device can be explained by referring to the foregoing embodiments, and will not be repeated here.

[0101] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method as described above.

[0102] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0103] This application also provides a computer program product containing instructions, including a computer program / instructions that, when executed by a processor, implement the method as described above.

[0104] The functions and effects achieved in this embodiment can be explained by referring to other embodiments, and will not be repeated here.

[0105] It is understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the invention.

[0106] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0107] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and the implementation methods in this application are not limited in this respect.

[0108] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application 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 application includes any and all combinations of one or more of the associated listed items. The singular forms "a," "the," and "the" as used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0109] It is understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0110] It is understood that the memory in the embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM). It should be noted that the memory in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the aforementioned method implementations, and will not be repeated here.

[0113] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0114] 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 units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0115] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0116] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this invention should be determined by the scope of the claims.

Claims

1. A method for displaying an interface, characterized in that, include: A display interface is provided; wherein the display interface includes a first dynamic component and a second dynamic component; When the first dynamic component receives a trigger operation, it generates a first change request and sends the first change request to the server; wherein, the first change request includes first state change data; the first state change data is used to characterize the state change that the first dynamic component needs to perform; Upon receiving a trigger operation, the second dynamic component generates a second change request and sends the second change request to the server; wherein, the second change request includes second state change data; the second state change data is used to characterize the state change that the second dynamic component needs to perform; Wherein, if the second dynamic component receives the trigger operation but has not yet received the response data corresponding to the first change request, the second change request also includes the first state change data.

2. The method according to claim 1, characterized in that, The method further includes: The first change request is added to the task queue, and upon receiving the response data corresponding to the first change request, the first change request is removed from the task queue. If the second dynamic component receives a trigger operation but does not receive response data corresponding to the first change request, it generates a second change request including the first state change data and the second state change data, and adds the second change request to the task queue.

3. The method according to claim 2, characterized in that, The method further includes: If a response data corresponding to the second change request is received, but no response data corresponding to the first change request is received, the display interface is updated according to the response data of the second change request, and the first change request is removed from the task queue; wherein, the response data of the second change request includes display data corresponding to the first state change data and display data corresponding to the second state change data.

4. The method according to claim 2, characterized in that, The first change request and the second change request each have a request identifier; The response data corresponding to the first change request carries the request identifier of the first change request, and the response data corresponding to the second change request carries the request identifier of the second change request.

5. The method according to claim 1, characterized in that, The first change request and the second change request each further include interface component state representation data of the display interface; wherein, the interface component state representation data is used to represent the component composition and component state of the display interface; the interface component state representation data is used by the server to restore the interface data corresponding to the display interface based on the interface component state representation data, adjust the interface data according to the first state change data and / or the second state change data, regenerate the interface component state representation data representing the adjusted interface data, and put the interface component state representation data of the adjusted interface data into the response data of the first change request and the response data of the second change request.

6. A method for displaying an interface, characterized in that, include: The system receives a first change request and a second change request from the client in parallel. The first change request includes first state change data, which characterizes the state change that a first dynamic component needs to perform. The second change request includes the first state change data and the second state change data, which characterizes the state change that a second dynamic component needs to perform. The system asynchronously responds to the first change request and the second change request, generating response data for the first change request and for the second change request; wherein the response data for the first change request includes display data corresponding to the first state change data; and the response data for the second change request includes display data corresponding to the first state change data and display data corresponding to the second state change data. The response data of the first change request and the response data of the second change request are asynchronously sent to the client.

7. The method according to claim 6, characterized in that, The method further includes: The client's interface access request was received; Obtain interface data corresponding to the interface access request and interface component state characterization data corresponding to the interface data; the interface data includes a first dynamic component and a second dynamic component; wherein, the interface component state characterization data is used to characterize the component composition and component state of the interface data; Send response data corresponding to the interface access request to the client; wherein the response data for the interface access request includes the interface data and the interface component state representation data.

8. The method according to claim 6, characterized in that, The first change request and the second change request each carry interface component status representation data; the interface component status representation data respectively represent the component composition and component status of the corresponding displayed interface when the client issues the first change request or the second change request; Asynchronously responding to the first change request and the second change request, generating response data corresponding to the first change request and the second change request, including: Upon receiving the first change request, the interface data of the corresponding display interface is restored according to the interface component state representation data carried in the first change request, the component state of the first dynamic component is adjusted based on the first state change data, the display data of the adjusted first dynamic component is generated, and the display data of the adjusted first dynamic component is sent to the client. Upon receiving the second change request, the interface data of the corresponding display interface is restored according to the interface component state representation data carried in the second change request. The component state of the first dynamic component is adjusted based on the first state change data, and the adjusted display data of the first dynamic component is generated. The component state of the second dynamic component is adjusted based on the second state change data, and the adjusted display data of the second dynamic component is generated. The adjusted display data of the first dynamic component and the adjusted display data of the second dynamic component are then sent to the client.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the method as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 8.

Images