1. Why do packaging?Facilitates overall code calling, public processing of requests, and personalized customization 2. Others have already encapsulated a lot, why not just modify and use it?
3. Personal packaging demoCode structure [based on vue] Basic idea Store all request interface addresses by module according to files, such as request/module/user user information related module [service] 2. Encapsulation methods and classes. Bind common request methods to all requests and process path parameters on the request URL generateServer.js import server from "../util/axiosConfig"; // Modify the basic configuration of axios and request configuration function request({ url, method = "get", queryParm = {}, body = {}, pathParm = null, config = {}, }) { const configAxios = { method, ...config, url: dealRequestUrl(url, pathParm), }; switch (method) { case "get": configAxios.params = queryParm; break; default: // Request methods 'PUT', 'POST', and 'PATCH' configAxios.data = body; break; } console.log('configAxios', configAxios) return server(configAxios); } function dealRequestUrl(url, pathParm) { if (!pathParm) return url; let dealurl = url; Object.keys(pathParm).forEach((ele) => { dealurl = dealurl.replace(`{${ele}}`, pathParm[ele]); }); return dealurl; } class GenerateServer { constructor(url) { this.url = url; } getdata(parm) { console.log('parm', parm) return request({ ...parm, method: "get", url: this.url }); } postdata(parm) { return request({ ...parm, method: "post", url: this.url }); } deletedata(parm) { return request({ ...parm, method: "delete", url: this.url }); } } export default GenerateServer; 3. Expose the whole use import { userInfoServer } from "./request"; . . . // Send request userInfoServer.getUserName .getdata({ queryParm: { id: 223, }, }) .then((res) => { console.log("res", res); }); // Send request userInfoServer.getUserName .postdata({ body: { id: 223, }, }) .then((res) => { console.log("res", res); }); // Send a get request with the request path containing the parameter userInfoServer.getUserList .getdata({ queryParm: { id: 223, }, pathParm: { id: 567, }, }) .then((res) => { console.log("res", res); }); Summarize:The above encapsulation is mainly to split the request in a more detailed way to facilitate maintenance. It is also more convenient during development. For new interface requirements, you only need to add URl configuration and response generator configuration in the corresponding module. Then you can process the request in the business code. The path parameters and request body parameters are encapsulated, so you don't need to worry about the corresponding configuration when using them. The above code does not handle file uploads, get request parameter strings, etc. But just add configuration in the corresponding axios. Easy to maintain. This is the end of this article about Axios secondary packaging in the project. For more relevant Axios secondary packaging content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future! Code git: git You may also be interested in:
|
<<: Detailed explanation of how to install PHP7 on Linux
>>: In-depth explanation of the maximum value of int in MySQL
You can add comments to MySQL SQL statements. Her...
Overview MySQL also has its own event scheduler, ...
Preface For the permissions of files or directori...
Before using idea to write JSP files, you need to...
Execute the command: docker run --name centos8 -d...
First find out where the configuration file is wh...
Today, when I was on the road, a colleague sent m...
A record of an online MySQL transaction problem L...
Preface Not long ago, I combined browser-sync+gul...
SQL statement /* Some methods of eliminating dupl...
Table of contents Using routing plugins in a modu...
Table of contents How to deploy MySQL service usi...
Table of contents environment Install CentOS Conf...
Table of contents How to rename MySQL database Th...
Method 1: Use the SET PASSWORD command First log ...