the question is, what's the situation?
There are more Ajax requests in the Web page, or AJAX is used to exchange data with the backend at the beginning of the application. (That's what I'm currently involved in.) N-Interface debugging is a hassle in the back and forth.
It is not possible for the backend to write all of the interfaces for a short time, or to create fake data and interfaces for front-end testing, not only time-consuming but also a number of changes to the data structure and interface names returned in the development phase. Then the back end writes the interface to the front end, which looks good. But in the implementation process, the back-end of the interface may be wrong, you need to constantly and back-end communication constantly looking for the reason, it is possible to stagnate and wait for back-end return data is
can continue.
why is that?
1: The front end relies on an unformed interface at the beginning of development.
2: The backend does not fully know the data items and data format required by the front-end.
How to solve?
1: Requirements confirmation meeting the front and back end fully discuss the function and interface. (backlog, this job is very simple)
In the context of a well-established backlog document, each operation of the user is recorded as a clear function. As long as the developer agrees with these entries in the final confirmation, it is easy to summarize the interfaces that are needed.
2: Front-End Write interface document (backend assist).
Why the front end?
1: The front end fully understand the data that the page needs to display. 2: The front-end fully understand the required data format (how to handle error codes, etc.)
The front-end interface document may be like this: (Sample login interface)
Copy Code code as follows:
: User Login
Url:? (left to back end to add)
Request Method: POST
Request parameter: email:string
Pwd:string
Checkcode:string
Return Data:
{
code:int,//error encoding, login succeeded for 0 other errors return error code, no result item
result:{
Id:int//User ID
name:string//user name
...
}
}
How is the back end assisted?
1: Supplemental request URL. 2: Fix the field that returns the data. If you return a data item many of the fields in the document do not conform to the backend development field, then the backend needs to be modified.
Modifying a document is a process of discussion back and forth, with any questions you can communicate. One copy of the document after completion. (Any changes in the document can be labeled with a different color, reminding other people to note)
This may be the case after the back end is fully replenished:
Copy Code code as follows:
: User Login
Url:user/login.php (Supplementary)
Request Method: POST
Request parameter: email:string
Pwd:string
Checkcode:string
Return Data:
{
code:int,//error encoding, login succeeded for 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 completion of the document, it is clear to all of us that if I do this, it must be true to return and use such data.
The back end begins to write code, completely ignoring the front end, he will not come to find you trouble.
How does the front end work according to the document?
The interface is all there, and the return data is also available. The next step is to build a framework that can be tested with mock data.
If you use jquery, a simple structure might be like this.
The user clicks on the login button, the front end simulates the data described in the document, and calls the callback function directly. This is the same as the real situation.
Copy Code code 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 Tips
},
Success:function (data) {
if (data && data.code!= 0) {
Common.showerror (data);
Error handling code translates to text hints to users
};
Success && success (data);
}
});
}
};
1: User Login
function login (email, pwd, Checkcode, callback) {
Test environment
var data = {//Analog
code:0,
result:{
ID: ' 123456 ',
User: "Lujun"
}
};
callback (data);//directly pass the analog to the callback function
return;
---to link the real data to annotate the above code, before the line through the compression tool these comments will be removed
Formal environment
Common.post ("user/login.php", {email:email, pwd:pwd, Checkcode:checkcode}, callback);
};
Click event Driver Login
Login successfully performs some column actions
$ (' #submit '). Click (function () {
var email = $ (' #email '). Val ();
var pwd = $ (' #pwd '). Val ();
var Checkcode = $ (' #checkCode '). Val ();
Calling the Login interface
Login (email, pwd, checkcode, function (data) {
if (data && Data.code = = 0) {
Ajax execution succeeded
data = Data.result;
$ (' #userName '). Text (Data.user);
Other code ...
}
});
});
How to do a better job?
All functional interfaces are working in this way, it will be found that the entire application does not require back-end support, full use of analog data can be accepted test, is not cool a bit!
Once you are ready to link the official data, comment out the test code (this may be distributed across all corners of the code, 10 or more). You can't switch quickly in the test environment, the linked database environment!
Such a test code is too limited in value.
We can separate the test data as a file, overwriting the bottom of the Ajax request method using the method overlay.
Copy Code code as follows:
View Code
Testdata.js is used to store all test data
TestData = {
"Userlogin": {//Log in test data
code:0,
result:{
ID: ' 123456 ',
User: "Lujun"
}
}
// ... Test of other structures tiger crouching
};
Common.js
Overlay 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 a key, so that you can omit so many judgments
if (url = = "user/login.php") {
Success (testdata["Userlogin"]);
}else if (url = = ' other ') {//other interface
//...
}
};
1: User Login
function login (email, pwd, Checkcode, callback) {
Common.post ("user/login.php", {email:email, pwd:pwd, Checkcode:checkcode}, callback);
};
Click event Driver Login
Login successfully performs some column actions
$ (' #submit '). Click (function () {
var email = $ (' #email '). Val ();
var pwd = $ (' #pwd '). Val ();
var Checkcode = $ (' #checkCode '). Val ();
Calling the Login interface
Login (email, pwd, checkcode, function (data) {
if (data && Data.code = = 0) {
Ajax execution succeeded
data = Data.result;
$ (' #userName '). Text (Data.user);
Other code ...
}
});
});
The above code is easy to understand, when you want to simulate data testing, the bottom of the Ajax request method is overwritten.
Of course this is just one of them, you might have a better way or you can switch two environments with a global variable, like debug = False, Debug = true!
last
The method is very simple in fact, and it is important to backlog and understanding in scrum.
The team I work with now works very well in this way.
And finally I've been thinking about a merge obfuscation compression with 500K JS application How to organize code?
