Method, system and terminal for optimizing front-end data interaction on basis of fetch

Abstract

The present application relates to the technical field of Web program development, and in particular to a method, system and terminal for optimizing front-end data interaction on the basis of fetch. Different from traditional xhr-based data interaction methods, the present application uses a native fetch technology, so that not only the requirements of data interaction are met, but also advanced customization settings, such as custom timeout duration, cache configuration, request / response interceptors, request header / response parsing settings, and standardized error / exception handling, are provided, enriching the data request process and forming full-process support for service scenarios; additionally, the method natively supports Promise, and compared with traditional technologies, the method avoids callback hell, has better performance, easier integration and better maintainability, and thus has greater advantages over other traditional data request methods in terms of accommodating diverse service scenarios and integration requirements.

Description

A method, system and terminal for optimizing front-end data interaction based on fetch

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on December 13, 2023, with application number 202311712625.6 and invention name “A method for optimizing front-end data interaction based on fetch”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application belongs to the technical field of Web program development, and specifically relates to a method, system, and terminal for optimizing front-end data interaction based on fetch. Background Art

[0004] Ajax, which stands for "Asynchronous Javascript And XML", refers to a web development technology for creating interactive and dynamic web applications. It can asynchronously update part of the web page content without reloading the entire web page.

[0005] Compared with the traditional form-based technology model, it significantly improves user response and saves server-side bandwidth, resource and other overheads. Therefore, more and more products use Ajax technology to build rich internet applications.

[0006] In traditional Ajax technology, XHR (XMLHTTPRequest) is the core, and data communication is completed by registering event callbacks in advance and responding to data sent by the server. However, there are the following problems:

[0007] 1. The function is single and only completes one data interaction. It is difficult to catch exceptions or errors that occur during the interaction.

[0008] 2. Lack of timeout, interception, caching and other functions, making it difficult to meet daily development needs;

[0009] 3. Registering event callbacks can easily lead to callback nesting ("callback hell"), which makes debugging and maintenance difficult and increases code complexity.

[0010] 4. The framework based on this encapsulation is not easy to maintain in the future, and it is difficult to support custom new functions. Summary of the Invention

[0011] The purpose of this application is to provide a method, system and terminal for optimizing front-end data interaction based on fetch, which can solve the technical problems of single function and difficult code maintenance and use in traditional technologies.

[0012] The technical solutions adopted in this application are as follows:

[0013] A method for optimizing front-end data interaction based on fetch, comprising:

[0014] Obtaining a webpage configuration and its corresponding configuration parameters, wherein the webpage configuration includes a global configuration and a local configuration, wherein the local configuration overrides the global configuration, and the configuration parameters include a cache switch, a request path prefix, a URL encoding, a request method, a request header, a response parsing setting, a request parameter data structure, common parameters, a timeout period, and a standard response success status code;

[0015] Get the business requirements and the request method of the business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;

[0016] Turn on the cache switch and check whether there is cached data corresponding to the business needs in the local cache. If the cached data exists in the local cache, it will be directly called. Otherwise, a fetch request will be sent to the server.

[0017] Obtaining the response data corresponding to the fetch request from the server, and synchronously generating a success status code for the response to be evaluated, and then comparing the success status code for the response to be evaluated with the standard success status code for the response;

[0018] If the response success status code to be evaluated is consistent with the standard response success status code, then processing the corresponding response data according to the state of the cache switch;

[0019] If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

[0020] In an optional solution, when the cache switch is turned on for the first time, the server data is requested and the server data is saved in the local storage.

[0021] In an optional solution, the request path prefix is ​​used to store the common path of the request, the common parameters are used to store the common parameters in the request, and the request parameter data structure supports URL, FORM form, and JSON structure to be submitted to the server to adapt to the server data requirements.

[0022] In an optional solution, before sending the fetch request to the server, if there is a request interceptor for verifying the validity of the parameters, the business layer passes the request URL and request parameters to the request interceptor array. The fetch request will not be issued until all the request interceptors are executed. Otherwise, the fetch request is generated directly.

[0023] In an optional solution, after the business demand is generated, a timeout listener is started to monitor the data response duration. After the data response returns with a timeout, the listener code is executed, and subsequent responses are canceled, and the timeout error is reported to the business layer. Conversely, if the data response returns without a timeout, the listener code execution is canceled and a fetch request is generated.

[0024] In an optional solution, after the fetch request is sent to the server, the server status and network status are collected in real time;

[0025] If the server status or network status is abnormal, a server error is thrown to the business layer and the subsequent process is terminated. Otherwise, the server obtains the data and indicates that the fetch request response is successful.

[0026] In an optional solution, the steps after the fetch request response is successful include:

[0027] Parse the response data according to the web page configuration, set the response interceptor, and the server passes the request URL and response data to the response interceptor array;

[0028] If the response interceptor returns an error, all subsequent program executions are terminated and the interceptor error is thrown to the business layer;

[0029] If all response interceptors are executed and no errors are returned, a success status code for the response to be evaluated is generated synchronously.

[0030] In an optional solution, the step of processing corresponding response data according to the state of the cache switch includes:

[0031] Get the status of the cache switch to determine whether it is enabled;

[0032] If the cache switch is turned on, the response data is added to the local storage;

[0033] If the cache switch is turned off, the response data is directly filtered out.

[0034] The present application also provides a system for optimizing front-end data interaction based on fetch, which is applied to the above-mentioned method for optimizing front-end data interaction based on fetch, and the system includes:

[0035] A configuration module, configured to obtain a webpage configuration and its corresponding configuration parameters, wherein the webpage configuration includes a global configuration and a local configuration, wherein the local configuration overrides the global configuration, and the configuration parameters include a cache switch, a request path prefix, a URL encoding, a request method, a request header, a response parsing setting, a request parameter data structure, common parameters, a timeout period, and a standard response success status code;

[0036] The request module is used to obtain business requirements and the request method of the business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;

[0037] The calling module is used to turn on the cache switch and query whether there is cached data corresponding to the business demand in the local cache. If the cached data exists in the local cache, the cached data is directly called. Otherwise, a fetch request is sent to the server.

[0038] A response module, configured to obtain response data corresponding to the fetch request from the server, and simultaneously generate a response success status code to be evaluated, and then compare the response success status code to be evaluated with a standard response success status code;

[0039] If the response success status code to be evaluated is consistent with the standard response success status code, then processing the corresponding response data according to the state of the cache switch;

[0040] If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

[0041] And, a terminal for optimizing front-end data interaction based on fetch, comprising:

[0042] at least one processor;

[0043] and a memory communicatively coupled to the at least one processor;

[0044] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the above-mentioned method for optimizing front-end data interaction based on fetch.

[0045] The technical effects achieved by this application are:

[0046] This application is different from the traditional XHR-based data interaction method. It adopts native fetch technology. While meeting data interaction, it provides advanced customization settings such as custom timeout, cache settings, request interceptors, response interceptors, request headers, response parsing settings, and exception standardization processing. It enriches the data request process and forms full-process support for business scenarios. At the same time, the underlying layer of this method naturally supports Promise. Compared with traditional technologies, there is no callback hell, and it has better performance, easy access and maintainability. It has more advantages than other traditional data request methods in meeting multiple business scenarios and usage docking. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG1 is a flowchart of fetch request generation provided by this application;

[0048] FIG2 is a flow chart of the response to the fetch request provided in this application. DETAILED DESCRIPTION

[0049] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are described in detail below in conjunction with the drawings in the specification.

[0050] In the following description, many specific details are set forth to facilitate a full understanding of the present application. However, the present application may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present application. Therefore, the present application is not limited to the specific embodiments disclosed below.

[0051] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present application. The phrase "in a preferred embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it constitute a separate or selective embodiment that is mutually exclusive with other embodiments.

[0052] Referring to Figures 1 and 2 , this application provides a method for optimizing front-end data interaction based on fetch, including:

[0053] S1. Obtain a webpage configuration and its corresponding configuration parameters, wherein the webpage configuration includes global configuration and local configuration. The local configuration overrides the global configuration. The configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period, and standard response success status code;

[0054] S2. Obtain the business requirements and the request method of the business requirements, turn on the switch for wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;

[0055] S3. Turn on the cache switch and check whether there is cached data corresponding to the business needs in the local cache. If the cached data exists in the local cache, it is directly called. Otherwise, a fetch request is sent to the server.

[0056] S4. Obtain the response data corresponding to the fetch request from the server, and simultaneously generate a success status code for the response to be evaluated, and then compare the success status code for the response to be evaluated with the standard success status code for the response;

[0057] If the success status code of the response to be evaluated is consistent with the standard success status code of the response, the corresponding response data is processed according to the status of the cache switch;

[0058] If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

[0059] As shown in steps S1 to S4 above, with the rapid development of the Internet, front-end technology is also constantly improving. In this process, data interaction has become an important part of front-end development. Traditional front-end data interaction methods mainly rely on libraries such as XMLHttpRequest (XHR) and jQuery. However, these methods have performance bottlenecks when processing large amounts of data, resulting in poor user experience. In order to solve this problem, Fetch API came into being. Fetch API is a modern network request API that provides a global fetch() method that can be used to obtain resources. The design goal of Fetch API is to provide a simple, reasonable and controllable way to handle network requests, allowing developers to focus more on data processing and business logic. However, despite Fetch API is superior to traditional XHR and jQuery in many aspects, but it still has certain limitations, such as problems in error handling and timeout control. In this embodiment, the global configuration and local configuration are first extracted from the given web page configuration. Among them, the global configuration involves the macro settings of the entire web page, while the local configuration is more specific, covering the detailed configuration of a specific area. These configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period and standard response success status code, which provide detailed information for the server and business layer to understand and process the web page configuration. In the process of obtaining business needs, the server will pay special attention to the request method and turn on the switch to package data in the body. This step is to merge the body.data object into the body , and delete the original body.data object. This processing makes the data more centralized and concise, which is convenient for subsequent data processing and analysis. After turning on the cache switch, the business layer will query whether there is cached data corresponding to the business needs in the local cache. If it exists, the business layer will directly call the cached data. If not, it will send a fetch request to the server. This design effectively reduces unnecessary network requests and improves efficiency. After obtaining the response data corresponding to the fetch request from the server, it will synchronously generate a pending response success status code. Then, it will compare this pending response success status code with the standard response success status code. If the two are consistent, the corresponding response data will be processed according to the status of the cache switch. If the two are inconsistent, the request will be interrupted and an error report will be generated. This processing method ensures the accuracy and consistency of the data.

[0060] In a preferred embodiment, when the cache switch is turned on for the first time, the server data is requested and saved in the local storage. Subsequently, when the business demand is issued, the local cache will be queried first to see whether there is cache data corresponding to the business demand, thereby reducing the generation of unnecessary network requests.

[0061] In a preferred embodiment, the request path prefix is ​​used to store the common path of the request, the common parameters are used to store the common parameters in the request, and the request parameter data structure supports URL, FORM form, and JSON structure submission to the server to adapt to the server data requirements.

[0062] Globally define the path prefix and interceptor, and use POST to submit JSON data to the server to complete data interaction.

[0063] [Corrected 26.12.2024 in accordance with Rule 26] The main code is as follows:

[0064] The implementation steps are as follows:

[0065] 1) Set the project prefix prefix, which will be appended to all requests;

[0066] 2) Set up a response interceptor. When the return code is core.e1019 (not logged in), the current page is refreshed and false is returned to prevent the execution of subsequent code.

[0067] 3) The business calls ctFetch (the function name implemented in this patent);

[0068] 4) Merge method, transferType with global configuration;

[0069] 5) data is merged into the body parameter of fetch;

[0070] 6) Due to the prefix setting, the request URL becomes / gw / user;

[0071] 7) Since it is a POST request, you need to set the HTTP request header to application / json;

[0072] 8) Issue a fetch request;

[0073] 9) Data is returned normally;

[0074] 10) Parse the returned data;

[0075] 11) Execute the response interceptor, the logic has been described in step 2;

[0076] 12) Check whether the response status code is consistent

[0077] 13) Return the parsed data res from the server to the business, and the whole process ends.

[0078] In a preferred embodiment, before sending a fetch request to the server, if there is a request interceptor for verifying the validity of the parameters, the business layer passes the request URL and request parameters to the request interceptor array. The fetch request will not be issued until all request interceptors are executed. Otherwise, the fetch request is generated directly.

[0079] In this implementation, before sending a fetch request to the server, it is first necessary to consider the case where there is a request interceptor for verifying parameter validity. In this case, the business layer will pass the request URL and request parameters to the request interceptor array. Each request interceptor will verify the request parameters to ensure the validity of the parameters. Only when all request interceptors have been executed and the validity of the parameters has been ensured will the fetch request be actually issued. Conversely, if there is no request interceptor for verifying parameter validity, the business layer will directly generate a fetch request without waiting for any additional verification steps. This design can ensure the timeliness and efficiency of requests and avoid unnecessary waiting time.

[0080] In a preferred embodiment, after the business demand is generated, a timeout listener is started to monitor the data response duration. After the data response returns with a timeout, the listener code is executed, the subsequent response is canceled, and the timeout error is reported to the business layer. Conversely, if the data response returns without a timeout, the listener code execution is canceled and a fetch request is generated.

[0081] In this embodiment, after the business demand is generated, the timeout listener is enabled. Once the data response time exceeds the predetermined threshold, the device will trigger the execution of the pre-set code and cancel the subsequent response in time to avoid unnecessary resource consumption. At the same time, the device will report the timeout error to the business layer so that the business layer can understand and handle the problem in time. If the data response time does not exceed the predetermined threshold, the timeout listener will remain silent and wait for the next data response task, providing strong data protection for the business layer.

[0082] Among them, after the fetch request is sent to the server, the server status and network status will be collected in real time;

[0083] If the server status or network status is abnormal, a server error is thrown to the business layer and the subsequent process is terminated. Otherwise, the server obtains the data and indicates that the fetch request response is successful.

[0084] In a preferred embodiment, the steps after the fetch request response is successful include:

[0085] Parse the response data according to the web page configuration, set the response interceptor, and the server passes the request URL and response data to the response interceptor array;

[0086] If the response interceptor returns an error, all subsequent program executions are terminated and the interceptor error is thrown to the business layer;

[0087] If all response interceptors are executed and no errors are returned, a success status code for the response to be evaluated is generated synchronously.

[0088] As mentioned above, after the fetch request is successful, the response data is first parsed according to the configuration information of the web page, and a response interceptor is set. This interceptor starts running after the server passes the request URL and response data. It passes these data to the response interceptor array for subsequent processing. Then, if the response interceptor returns an error, the execution of all subsequent programs will be terminated immediately, and the interceptor error will be thrown to the business layer, so that the business layer can quickly understand and handle the problem. Finally, if all response interceptors are executed and no error is returned, a response success status code to be evaluated will be generated synchronously. This status code can be used to determine whether the request is successful and how the response data should be processed after success. In this way, we can ensure that all steps are executed correctly after the request is successful and the response data can be processed effectively.

[0089] The step of processing the corresponding response data according to the state of the cache switch includes:

[0090] Get the status of the cache switch to determine whether it is enabled;

[0091] If the cache switch is turned on, the response data is added to the local storage;

[0092] If the cache switch is turned off, the response data will be directly filtered out.

[0093] In this embodiment, the cache switch is set for the local cache, that is, after the cache switch is turned on, the server response data can be added to the local cache to facilitate direct calls from the subsequent business layer. The response data in the local cache can be set according to the user's needs or according to the call frequency. Its purpose is to speed up data response and reduce unnecessary network requests.

[0094] The present application also provides a system for optimizing front-end data interaction based on fetch, which is applied to the above-mentioned method for optimizing front-end data interaction based on fetch, and the system includes:

[0095] Configuration module, which is used to obtain web page configuration and its corresponding configuration parameters. The web page configuration includes global configuration and local configuration. The local configuration overrides the global configuration. The configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period, and standard response success status code;

[0096] The request module is used to obtain business requirements and the request method of the business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object;

[0097] The calling module is used to turn on the cache switch and query whether there is cached data corresponding to the business needs in the local cache. If the cached data exists in the local cache, the cached data is directly called. Otherwise, a fetch request is sent to the server.

[0098] The response module is used to obtain the response data corresponding to the fetch request from the server, and simultaneously generate the response success status code to be evaluated, and then compare the response success status code to be evaluated with the standard response success status code;

[0099] If the success status code of the response to be evaluated is consistent with the standard success status code of the response, the corresponding response data is processed according to the status of the cache switch;

[0100] If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

[0101] In the above, when the system is executed, it first obtains the configuration information and parameters of the web page through the configuration module, then obtains the business requirements through the request module, turns on the switch to include data in the request body, merges the body.data object into the request body, and deletes the original body.data object. Then, it uses the call module to query whether there is cached data corresponding to the business requirements in the local cache. If it exists, the cached data is used directly; if it does not exist, a fetch request is sent to the server, and finally the corresponding module is executed to respond to the fetch request and output the corresponding response data.

[0102] And, a terminal for optimizing front-end data interaction based on fetch, comprising:

[0103] at least one processor;

[0104] and a memory communicatively coupled to the at least one processor;

[0105] The memory stores a computer program that can be executed by at least one processor, and the computer program is executed by at least one processor so that the at least one processor can execute the above-mentioned method for optimizing front-end data interaction based on fetch.

[0106] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, apparatus, article, or method comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, apparatus, article, or method. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, apparatus, article, or method comprising the element.

[0107] The above are merely optional implementations of the present application. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present application, and such improvements and modifications should be considered within the scope of protection of the present application. Structures, devices, and operating methods not specifically described or explained in this application shall, unless otherwise specified or limited, be implemented in accordance with conventional means in the art.

Claims

1. A method for optimizing front-end data interaction based on fetch, characterized by: include: Obtaining web page configuration and its corresponding configuration parameters, wherein the web page configuration includes global configuration and local configuration, the local configuration overrides the global configuration, and the configuration parameters include cache switch, request path prefix, URL encoding, request method, request header, response parsing settings, request parameter data structure, common parameters, timeout period, and standard response success status code; Get the business requirement and the request method of the business requirement, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object; Turn on the cache switch and query whether there is cache data corresponding to the business needs in the local cache. If there is cache data in the local cache, directly call the cache data. Otherwise, send a fetch request to the server. Obtaining response data corresponding to the fetch request from the server, and synchronously generating a response success status code to be evaluated, and then comparing the response success status code to be evaluated with a standard response success status code; If the response success status code to be evaluated is consistent with the standard response success status code, processing the corresponding response data according to the state of the cache switch; If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

2. The method for optimizing front-end data interaction based on fetch according to claim 1, characterized in that: When the cache switch is turned on for the first time, the server data is requested and the server data is saved in the local storage.

3. The method for optimizing front-end data interaction based on fetch according to claim 1 is characterized in that: The request path prefix is ​​used to store the common path of the request, the common parameters are used to store the common parameters of the request, and the request parameter data structure supports URL, FORM form, and JSON structure to be submitted to the server to adapt to the data requirements of the server.

4. The method for optimizing front-end data interaction based on fetch according to claim 1 is characterized in that: Before sending the fetch request to the server, if there is a request interceptor for verifying the validity of the parameters, the business layer passes the request url and request parameters to the request interceptor array, and the fetch request will not be issued until all the request interceptors are executed. Otherwise, the fetch request is directly generated.

5. The method for optimizing front-end data interaction based on fetch according to claim 1 is characterized in that: After the business demand is generated, a timeout listener for monitoring the data response duration is enabled. After the data response returns with a timeout, the listener code is executed, and subsequent responses are canceled, and a timeout error is reported to the business layer. Conversely, if the data response returns without a timeout, the listener code execution is canceled and a fetch request is generated.

6. The method for optimizing front-end data interaction based on fetch according to claim 1, characterized in that: After the fetch request is sent to the server, the server status and network status are collected in real time; If the server status or network status is abnormal, a server error is thrown to the business layer and the subsequent process is terminated. Otherwise, the server obtains the data and indicates that the fetch request response is successful.

7. The method for optimizing front-end data interaction based on fetch according to claim 6 is characterized in that: The steps after the fetch request is successfully responded to include: Parse the response data according to the web page configuration, set the response interceptor, and the server passes the request URL and response data to the response interceptor array; If the response interceptor returns an error, all subsequent program executions are terminated and the interceptor error is thrown to the business layer; If all response interceptors are executed and no error is returned, a success status code of the response to be evaluated is generated synchronously.

8. The method for optimizing front-end data interaction based on fetch according to claim 1, characterized in that: The step of processing corresponding response data according to the state of the cache switch includes: Get the status of the cache switch to determine whether it is enabled; If the cache switch is turned on, the response data is added to the local storage; If the cache switch is turned off, the response data is directly filtered out.

9. A system for optimizing front-end data interaction based on fetch, applied to the method for optimizing front-end data interaction based on fetch as claimed in any one of claims 1 to 8, characterized in that: The system comprises: A configuration module, the configuration module is used to obtain a web page configuration and its corresponding configuration parameters, wherein the web page configuration includes a global configuration and a local configuration, the local configuration overrides the global configuration, and the configuration parameters include a cache switch, a request path prefix, a URL encoding, a request method, a request header, a response parsing setting, a data structure of request parameters, common parameters, a timeout period, and a standard response success status code; A request module, which is used to obtain business requirements and request methods of the business requirements, turn on the switch of wrapping data in the body, merge the body.data object into the body, and delete the original body.data object; A calling module, which is used to turn on the cache switch, query whether there is cache data corresponding to the business demand in the local cache, and directly call the cache data if there is cache data in the local cache, otherwise, send a fetch request to the server; A response module, the response module is used to obtain response data corresponding to the fetch request from the server, and synchronously generate a response success status code to be evaluated, and then compare the response success status code to be evaluated with a standard response success status code; If the response success status code to be evaluated is consistent with the standard response success status code, processing the corresponding response data according to the state of the cache switch; If the response success status code to be evaluated is inconsistent with the standard response success status code, the request is terminated and an error report is generated.

10. A terminal for optimizing front-end data interaction based on fetch, characterized in that: include: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the method for optimizing front-end data interaction based on fetch as described in any one of claims 1 to 8.

Images