On the idea of "shutting down" in front-end development

What is a shut-off

The so-called roads lead to Rome, but if I were to design the various roads leading to Rome, I would at least do two things:

① let Rome have only one entrance

② let Rome have only one exit

The advantage of this is that no matter where you come from, I can unify all the signs at the entrance, and I can save you some memory when you leave Rome. Of course, Rome is not only an export entrance, but every exit must have the same rules, otherwise there will be problems.

Specific to today's work scene, the highway is a good example of a shut-off, when entering the highway through the toll station to do some signs, leaving the time will do some operations, if there is no such a shut-off, whether it is the payment of work, traffic statistics or other can not be counted.

Normal life has a variety of behavior, we will find that, although the efficiency will be lower, but it can be better management, the same principle can be applied to the front-end and even the entire program development, today we will talk about the front end of the various.

The text is only personal experience, if wrong please point out.

An example of a shut-down

Before we talked about the various benefits of working in the end (the downside is the cost to the user), and what are we going to do in front of the development?

In general, for the front-end, the request is a shut-off Ajax, and often friends will ask me some questions: How to repeat the request for the second time he did not request it?

In fact, the solution to this problem is a simple solution is to deal with Ajax:

1 var function (params) {2     // do some extra work, such as handling the params parameter 3     $.ajax (params)4 };

The solution here is to unify the underlying tampering with the Ajax success callback, to do a layer of data processing, but the benefit of the request interface is much more than this.

Encapsulate Request Parameters

First, we can add additional parameters to the underlying request parameters for each request, such as our and server-side conventions, each request we will have an extra head parameter, will carry some non-business public data:

1 head: {2     // Channel Sign 3     // Version Information 4     // Platform Information 5     NULL // extension information that may be required 6 }

Each request can solve many problems if it has additional information:

The ①server side knows which channel the current request originates from (SEM channel, traffic entry, search traffic entry ...). ), which version, which platform (IOS, Android, H5), maybe the server will be able to customize this request processing

② Assist KPI Assessment, such as marketing personnel to promote their products, and then to count his success today to promote how many single, will generate a two-dimensional code for this user, the specific URL is this:

Http://domain.com?channel=yexiaochai

Well, none of my requests (including the build order) will send the Channel field to the server side, and if the server is stored in the database, it will be easy to generate order fulfillment for all users every day.

③sem Channel is a large source of traffic (Buy search keywords), if we want to get every keyword on our system every page of the amount of access, can also be in this public parameters to do processing

④ based on the above functions, we can even set up a preliminary front-end funnel model based on these features in conjunction with a common statistical platform.

Unified data Processing

In general, each request interface has a fixed format for the data returned by the server side:

1 {2data   : {},// real Data 3   errno:0,// error code 4    msg: "Success"// information 5 }

Normal logic we only need to process data data, and the error code is not 0, we are playing a toast prompt msg error message, so we will be unified to modify the request callback, of course, some error code to do special processing (not logged, unauthorized), such as:

1 //Unified Processing Request return Data2 varCommondatahandler =function(data) {3     //Log Request return4     if(!data) {5Showtoast (' server error, please try again later ');6         return;7     }8     if(_.isstring (data)) data =json.parse (data);9     //Normal, no other logic is performedTen     if(Data.errcode = = 0)return true; One  A     //handling special cases where requests are not logged in -     if(Data.errcode = = error_code[' Not_login ')]) { -Showtoast (Data.errmsg,function () { the           //Execute unified logic, jump to landing page, ask to jump back after successful landing -         }); -         return false; -     } +     //handling other error codes that require special handling requires business development to customize the interface and write the processing logic to a specific page -     if( This. Errcodecallback[data.errcode]) { +          This. Errcodecallback[data.errcode] (Data.errcode, data.errmsg, data); A         return false; at     } -     //generic error handling, popup toast directly -     if(Window. Apps && Data && data.errmsg) window. App.showtoast (Data.errmsg, This. Errorcallback); -     return false; -};

Of course, the beginning of the repeat request is no longer requested or can do this place, but the specific operation will have a lot of details to consider.

Do not use Ajax

Because the hybrid mode, the front end in addition to Ajax, there may be more choices, such as in the native container, the front end will not use Ajax to make a request, directly from the native agent issued, if the request did not seal, it will need to change all the business code, this is very unscientific.

Conclusion

Here is just a small point to show you the importance of the procedure, in fact, many of the small points in our program need to do the processing.

Localstorage use

As we said earlier, if you do not want to repeat the request, you need to use the caching technology, corresponding to the front end is localstorage, whenever we use the cache must consider how to update and cache expiration issues, this time we need to align the shell.

Jump

In order to do a single page application, we need to do a jump to do not break the route, we even need to window.location this jump to do the processing, to be encapsulated as a function.

About the actual work of the case is too many, small into the settimeout of the shell, the incident mechanism of the shell, large to account system, wallet system, such as the treatment, we should have in the actual work of this kind of thinking.

On the idea of "shutting down" in front-end development