Improving JavaScript code _javascript techniques with AOP

AOP is also called aspect-oriented programming, with spring's classmate must be very familiar with it, and in JS, AOP is a seriously neglected technical points, this article through the following few examples, to say that AOP in JS in the magical effect.

1, prevent the window.onload from being covered two times.
2, no intrusive statistical code.
3, separate form request and checksum.
4, add parameters dynamically to the AJAX request.
5, responsibility chain mode.
6, the combination replaces the inheritance.

First give the Before and after these 2 "slice" function. As the name suggests, let a function execute before or after another function, cleverly, before or after can and the current function public this and arguments, so we have more places to play.

The processing window.onload is covered two times.

Some time ago to see the QQ group has a person to ask questions, to rewrite window.onload, how to not window.onload the previous function of the cover off.

The original solution must be to add your new code directly to the original window.onload.

The disadvantage is very obvious, the need to change the original function, is the most intrusive one way.

Another slightly better solution is to save the previous window.onload with intermediate variables;

As a result, it takes a bit of extra cost to manage it, with a nasty intermediate variable __onload.

Think of this scene, when people feel cold, out of the time it is natural to choose to wear a mink coat, rather than rip off their skin for mink. The benefits of dynamic decoration are reflected in the complete invasion of the previous function.

Non-intrusive statistical code

The statistical code that does not have any association with logic is to be stuck into the function, which is believed that many students who have been reported are very unhappy. The following code, for example, is used to calculate how much time a function that creates 1000 nodes will take on a user's computer.

In an AOP way, you no longer need to make changes within a function to define a generic wrapper first.

As long as a line of code, you can give any function to add statistical time function.

Detach form requests and checksums

We often do some checking before submitting the form to determine if the form should be submitted properly. The worst writing is to put the logic of validation in the Send function.

A better way is to put all the validation rules in a set with a policy pattern, and return false or true to determine whether or not validation is passed. This allows you to randomly select and replace the checksum rules.

This also has a disadvantage, checksum send request these 2 requests are coupled to a function, we use AOP to separate them, validata into plug-ins, real Plug and play. Simply change the Send function to:

It's not hard to see the first Function.prototype.before code, we agreed that the current function returns false, blocking the execution of the next function, so when Validata returns false, the send is no longer executed. And because the previously mentioned before function can be common to this and arguments with the current function, the value parameter can also be passed smoothly into the Validata function.

Dynamically adding parameters to Ajax requests

In the first example, Window.onload is used after the post decoration, which is decorated with before front. Dynamically add some parameters before the AJAX request.

We've met a lot of Cross-domain requests, and JSONP and IFRAME are common ways. Previously, in our project, the JSONP request was represented by a parameter retype=jsonp, and Retype=iframe indicated that it was an IFRAME request. In addition to these 2 requests, the parameters are not any different. Then the retype parameters can be decorated dynamically with before.

First, define the proxy function for an AJAX request.

This function has no logical processing and branching statements, nor does it care whether it is a JSONP request or an IFRAME request. It is only responsible for sending data and is a good function of a single responsibility.

Next, place a before adorner before sending the request.

Start Sending Request:

Responsibility chain model.

The typical scenario of the responsibility chain pattern in JS is event bubbling. Link all child nodes and parent nodes together and pass events along this chain until a node can handle it. The responsibility chain pattern is the artifact that eliminates excessive if else statements.

Take a recent need to do a request for example, there is a file upload function, provided the control, HTML5, Flash, form upload these 4 ways of uploading. Determine which type of upload is currently selected based on their priority and browser support. Before I did the transformation, it's pseudo code was probably like this:

Of course, the actual code is far more than that, including a variety of control initialization, fault tolerance and so on. One day I need to block flash, it seems to be a very simple demand, but the difficulty is actually with the heart to tear down a string of wool similar.

If you try the chain of responsibility model, see how simple things will be:

The first step is to overwrite the previous after function so that when an object is returned it blocks the delivery of the responsibility chain and continues to deliver the request when NULL returns.

The next step is to wrap each control in its own function, ensuring that there is no logical crossover or contamination.

And then string them up with a chain of responsibilities:

It can be foreseen that one day I need to block flash, then I just need to change this line of code. Change into:

Combination instead of inheritance

A lot of times when we're designing a program, we run into the problem of using a combination or an inheritance. Generally, the use of a combination is more flexible and lightweight. Or take an example from the previous document.

I've defined a superclass upload, deriving 4 subclasses from the class.
Plugin_upload, Html5_upload, Flash_upload and Form_upload.

Plugin_upload inherits the parent class, obtains most of the functionality of upload, and then customizes some of the features that the control uploads. For example, the other 3 kinds of uploading methods are selected files will start uploading. The control upload passes through a file scan before it starts uploading.

The first approach is to plugin_upload inherit upload, and then rewrite its Start_upload method.

With a lighter combination, the original Start_upload function can be decorated with a scan function, even without the need to derive an extra subclass.