Let AJAX not depend on the back-end interface implementation solution_javascript skills

What is the problem?
There are more and more ajax requests in web pages, or the application has been using ajax to exchange data with the backend from the beginning. (This is the case for the projects I am currently involved in in the company) Debugging back and forth between the front and back ends of N multiple interfaces is a troublesome matter.
It is impossible for the backend to write all the interfaces in a short time, nor will it create fake data and interfaces for front-end testing. Not only is it time-consuming, but also there may be many data structures and interface names returned in the development stage. change. Then the backend writes the interface while providing it to the frontend, which looks good. However, during the specific implementation process, the unfinished interface of the backend may have errors. You need to constantly communicate with the backend to find the reasons. You may stop midway and wait for the backend to return the correct data before you can continue. .


Why is this? 1: The front-end relies on unformed interfaces in the early stages of development.
2: The backend does not fully know the data items and data formats required by the frontend.

How to solve it? 1: In the requirements confirmation meeting, the front-end and back-end fully discuss the functions and interfaces. (Backlog with clear requirements, this job is very simple)
With a complete backlog document, every operation of the user is recorded as a clear function. As long as the developers agree on these items in the final confirmation, it is easy to summarize the required interfaces.
　2: Front-end writing interface document (back-end assistance).

Why front-end? 1: The front-end fully understands the data that needs to be displayed on the page. 2: The front-end fully understands the required data format (how to handle error codes, etc.)
The front-end interface document may be like this: (Sample login interface)

Copy code The code is as follows:

: User login
url: ? (left to be supplemented by the backend)
Request method: POST
Request parameters: email:String
pwd:String
checkCode:String
Return data:
{
code:int,//Error code, successful login is 0. Other errors return error code, no result item
result:{
id:int // User ID
name:string // User name
...
}
}

How to assist the backend? 1: Supplementary request url. 2: Correct the fields of returned data. If the fields in many documents of the returned data items do not conform to the back-end development fields, then the back-end needs to be modified.
Modifying the document is a process of front-end and back-end discussion. If you have any questions, you can communicate. After the document is completed, each will have a copy. (Any modifications in the document can be marked with other colors to remind other people to pay attention)
After the backend is complete, it may look like this:

Copy code The code is as follows:

: User login
url: user/login.php (supplementary)
Request method: POST
Request parameters: email:String
pwd:String
checkCode:String
Return data:
{
code:int, // Error code, successful login is 0. Other errors return error code, no result item
result :{
id:int // User ID
user:string // Username (modified)
...
}
}

3: The development process is completely in accordance with the document
After the document is completed, everyone knows that as long as I do this, it will be correct to return and use such data.
Start writing code on the back end and ignore the front end at all. It will not trouble you at all.
How does the front end start working according to the documentation?
The interfaces are all there, and the return data is also there. Then the next step is to build a framework that can be tested using simulated data.
If using jquery, a simple structure might be like this.
The user clicks the login button, and the front end simulates the data described in the document and directly calls the callback function. This is true.

Copy code The code is as follows:

View Code
Common = {
post:function(url, data, success){//A basic post request encapsulation
$.ajax({
url:url ,
type:"post",
data:data,
dataType:"json",
error:function(){
//Common.tip(TipData["1002"] , 0);
//ajax error message
},
success:function(data){
if(data && data.code != 0){
//Common.showError (data);
//Convert the error handling code into text prompts for the user
};
success && success(data);
}
});
}
};
///1: User login
function login(email, pwd, checkCode, callback){
//Test environment
var data = { //Simulation data
code: 0 ,
result:{
id:'123456',
user:"lujun"
}
};
callback(data); // Directly pass the simulated data to the callback Function
return ;
//---Comment the above code when linking real data. These comments will be removed through the compression tool before going online
//Formal environment
Common.post(" user/login.php",{email:email, pwd:pwd, checkCode:checkCode}, callback);
};
//Click event-driven login
//Successful login to perform a series of actions
$('#submit').click(function(){
var email = $('#email').val();
var pwd = $('#pwd').val( );
var checkCode = $('#checkCode').val();
//Call the login interface
login(email, pwd, checkCode, function(data){
if(data && data.code == 0){
//ajax executed successfully
data = data.result;
$('#userName').text(data.user);
//Others Code...
}
});
});

How to work better?
All functional interfaces work in this way. You will find that the entire application does not require back-end support and can be accepted and tested completely with simulated data. Isn’t it a little cooler?
Once you are ready to link to the official data, comment out the test code (this may be distributed in every corner of the code, 10 or more places). You cannot quickly switch between the test environment and the environment connected to the database!
The value of such test code is too limited.
We can separate the test data as a file and use method coverage to cover the bottom-level AJAX request method.

Copy code The code is as follows:

View Code
//testData.js is used Store all test data
TestData = {
"userlogin":{ //Login test data
code : 0,
result:{
id:'123456',
user :"lujun"
}
}
// ... Testing of other structures
};
// common.js
// Override Common.post method
Common.post:function(url, data, success){//A basic post request encapsulation
//It is also a good idea to MD5 the url as the key, which can save so much judgment
if(url == "user/login.php"){
success(TestData["userlogin"]);
}else if(url == "other"){//Other interfaces
/ /...
}
};
/// 1: User login
function login(email, pwd, checkCode, callback){
Common.post("user/login.php ",{email:email, pwd:pwd, checkCode:checkCode}, callback);
};
//Click event-driven login
//Successful login to perform a series of actions
$(' #submit').click(function(){
var email = $('#email').val();
var pwd = $('#pwd').val();
var checkCode = $('#checkCode').val();
//Call the login interface
login(email, pwd, checkCode, function(data){
if(data && data.code = = 0){
//ajax executed successfully
data = data.result;
$('#userName').text(data.user);
//Other code...
}
});
});

The above code is easy to understand. When you want to simulate data testing, just overwrite the bottom-level ajax request method.
Of course this is just one of them, you may have a better way or you can switch between two environments through a global variable, just like debug = false, debug = true!
Finally
The method is explained thoroughly and is actually very simple. The important thing is the decomposition and understanding of the backlog in scrum.
My team is now working very well this way.
Finally, I have been thinking about how to organize the code for an application with 500K JS that is merged, obfuscated and compressed?