Shulou(Shulou.com)06/02 Report--

This article introduces the method of optimizing Web application in jQuery, the content is very detailed, interested friends can refer to it, I hope it can be helpful to you.

JQuery makes it easy to write good JavaScript-based Web applications, but it takes a few extra steps to make good Web applications better.

Sample application

Most of the tips in this article can be found in the accompanying sample application, which is an intuitive e-mail Web application. However, you can see how it evolved from * * articles, how its performance improved, and how these steps turned it into a powerful Web application.

Bind/Unbind

There are two functions in the Events module, bind () and unbind (), that accomplish the tasks of all other event methods. If you can add a click () method to a page element, why call bind ("click")? It's just a waste of time. However, these functions are very convenient in certain situations, and if used correctly, you can significantly improve the performance of your application.

These functions not only add events to specific page elements (like many other event methods in this module), but also remove them from page elements. Why would you do that? Let's take a look at the Web application and how to use these functions in specific situations.

Listing 1 shows the code for the above settings, which is the original code that was not improved:

$(document) .ready (function () {/ / cachethisquerysinceit'sasearchbyCLASS selectable=$ (": checked.selectable"); / / whentheselect/deselectallisclicked,dothisfunction $("# selectall") .click (selectAll); / / wheneveranyindividualcheckboxischecked,changethetext / / describinghowmanyarechecked selectable.click (changeNumFilters); / / calculatehowmanyareinitiallychecked changeNumFilters ();}); varselectable; functionchangeNumFilters () {/ / thisneedstobecheckedoneverycall / / sincethelengthcanchangewitheveryclick varsize=$ (": checked.selectable"). Length; if (size > 0) $("# selectedCount") .html (size) Else $("# selectedCount"). Html ("0");} / / handlestheselect/deselectofallcheckboxes functionselectAll () {varchecked=$ ("# selectall"). Attr ("checked"); selectable.each (function () {varsubChecked=$ (this) .attr ("checked"); if (subChecked benchmark) {$(this). Click ();}); changeNumFilters ();}

The code looks simple because I've used this widget in several articles. You saw the "select/deselectall" widget in the * * article, and I gave its basic form. In the performance article, you saw how to improve its performance by caching select queries and reducing the use of queries through CLASS. But there is one problem that needs to be solved. When you check the "select/deselectall" check box in a table that contains 100 rows, you get poor performance. In fact, in my browser, if you use this code, the average time to complete the selection is 3.4 seconds. The responsiveness is so bad! Even if various optimizations have been made, there are still some unacceptable aspects.

Let's take a closer look at the algorithm to see if something is wrong. You will iterate through each check box on the page to see if their current "checked" status is consistent with the "select/deselectall" check box. If it is inconsistent, call "click" on it to match the state of the "select/deselectall" check box. Wait a minute, you also need to add a function to these check boxes so that the changeNumFilters () function is called each time you click.

On closer inspection, you find that you have set up an algorithm that may call changeNumFilters () 101 times. No wonder the performance is so poor. Obviously, you don't need to update the count of selected messages each time you click, but you can do so after the process is complete. How can I avoid calling this method while clicking the check box?

Now, the unbind () method is starting to play its part. By calling unbind () before clicking the check box, you stop calling click () and avoid further calls to the changeNumFilter () method by click (). This is great! Now you won't call changeNumFilters () 101 times. However, this is only valid once, and after calling the click method, you need to use the bind method to add the click method back to each check box. Listing 2 shows the updated widget.

/ / handlestheselection/unselectionofallcheckboxes functionselectAll () {varchecked=$ ("# selectall"). Attr ("checked"); selectable.unbind ("click", changeNumFilters); selectable.each (function () {varsubChecked=$ (this) .attr ("checked"); if (subCheckedThe click ();}); selectable.bind ("click", changeNumFilters); changeNumFilters ();}

After these optimizations, the running speed of the check box is increased to about 900 milliseconds, thus greatly improving performance. These improvements come from going back to check what your algorithm is doing, as well as operations throughout the code. You can call the function only once instead of 100 times. By constantly improving this function in other articles in this series, you will make it faster and more efficient. But it doesn't have to be done. I also found the fastest algorithm that has never been disclosed before. In addition, if I show you the fastest algorithm too early, I won't be able to use it as the subject of this article. Hopefully, it will show you the benefits of using the bind/unbind feature in your code, if there is no better way.

Remember: use bind/unbind only when you do not want to trigger a default event, or as a temporary way to add or remove events to page elements

Listing 3 shows the fastest way to write the algorithm (if you have this widget in your code). It runs the function in only 40 milliseconds, far better than other previous methods.

FunctionselectAll () {varchecked=$ ("# selectall"). Attr ("checked"); selectable.each (function () {$(this) .attr ("checked", checked);}); changeNumFilters ();}

Live/Die

Two other powerful new features in jQuery 1.3 are the live () and die () functions. You can see its role in building well-designed Web applications through an example. Imagine adding a double click to each cell in the table. As a jQuery veteran, you should know that you want to set double-click in the document.ready () function, as shown in listing 4.

$("tr.messageRow") .dblclick (function () {if ($(this) .hasClass ("mail_unread")) {$(this) .removeClass ("mail_unread");}})

There is a problem with this design. It adds a double-click event to each row of a table that contains a messageRow class. But what happens if you add a new row to the table? For example, these lines might be displayed when you use Ajax to load additional messages into a page without reloading the page. This leads to a problem because the code written does not work. The event you create is bound to all the tr.messageRow elements that are displayed when the page is loaded.

It is not bound to any new tr.messageRow that you create during the life cycle of the page. Programmers who write similar code will eventually be disappointed because it doesn't work. Before the jQuery documentation discovers the problem, it may take hours for beginners in jQuery to figure out why their code doesn't work (which is what I experienced last year).

Before jQuery 1.3, there were three ways to solve this problem, but none of them were very good (for programmers using jQuery 1.2.x, they are still valid). The * * method is the reinitialization technique, which re-adds the event to the selected element each time a new element is added. The second method leverages bind/unbind, as shown in the previous section. Listing 5 shows these two methods.

/ / firsttechniquetodealwith "hot" pageelements,addedduringthepage's / / lifetime $("# mailtabletr#" + message.id) .addClass ("messageRow") .dblclick (function () {if ($(this) .hasClass ("mail_unread")) {$(this) .removeClass ("mail_unread") } / / secondtechniquetodealwith "hot" pageelements $("# mailtabletr#" + message.id) .addClass ("messageRow") .bind ("dblclick", (function () {if ($(this) .hasClass ("mail_unread")) {$(this) .removeClass ("mail_unread");}

Neither of these methods is very good. You may be writing code over and over again, or you may be forced to find points where new page elements may be added, and then deal with "hot elements" at those points. This is not a good way to program. However, jQuery may greatly simplify all this, and it can help us get a lot of things done.

Fortunately, there seems to be a plug-in that can solve this problem. This plug-in, called the LiveQuery plug-in, allows you to bind specific page elements to events, but only in an "active" manner, so all page elements, including those that come with when the page is created and those created during the life cycle of the page, can trigger events. This is a very smart and important plug-in for UI developers because it makes working with dynamic pages as simple as dealing with static pages. For Web application developers, it is a truly indispensable plug-in.

The jQuery core team realized the importance of the plug-in and included it in the 1.3 release. This "activity" feature is now part of the core jQuery, so any developer can take advantage of it. This feature is fully included in the 1.3 core code, except for a small number of events. I bet these unincluded events will appear in the next release of jQuery. Let's see how to use it to change the code.

("tr.messageRow") .live ("dblclick", function () {if ($(this) .hasClass ("mail_unread")) {$(this) .removeClass ("mail_unread");}

By making a small change to the code, the code is triggered when all tr.messageRow elements on the page are double-clicked. You can't see this behavior just using the dblclick () function, as described above. For this reason, I highly recommend that you use the live () method in most event methods. In fact, I think it is essential for any page that creates page elements dynamically, whether through Ajax or user interaction, using the live () function rather than the event method. It achieves a good tradeoff between easy to write and bug.

Remember: use the live () method when adding events to dynamic page elements. This makes events as dynamic as page elements.

Ajax Queue/Sync

Use Ajax calls in the server to become the metrics that Web2.0 companies measure themselves. We have discussed many times that using Ajax in jQuery is as simple as calling a normal method. This means that you can easily call any server-side Ajax function, just like calling the client-side JavaScript function. However, there are some shortcomings in the United States and China, and when there are too many Ajax calls to the server, there will be some negative effects. If the Web application uses too many Ajax calls, it can cause problems.

The problem is that some browsers limit the number of server connections that can be opened. In Internet Explorer, only 2 server connections are supported in the current version. Firefox supports opening eight connections, but it is still a limit. If the Web application does not control Ajax calls, it is likely to open more than two connections, especially if the server-side calls are time-intensive. This problem may be due to poor design of the Web application, or the user does not restrict the request. In either case, it is not desirable because you do not want the browser to decide which connections to use.

In addition, because the call is asynchronous, there is no guarantee that the response returned from the server will be in the same order as it was sent. For example, if you make two Ajax calls almost at the same time, you cannot guarantee that the server's responses will be returned in the same order. Therefore, there will be a problem if the second call depends on the results of * calls. Imagine a scenario in which * calls get data, and the second call manipulates the data on the client. If the response of the second call returns faster than * Ajax calls, your code will cause an error. You cannot guarantee the speed of response at all. When there are more calls, it is more likely to cause problems.

The creators of jQuery are aware of this potential problem, but also recognize that it will cause problems for only 1% of Web applications. But 1% of developers who develop Web applications need a solution. So a plug-in is created to screen for the problem by creating an Ajax Queue and an Ajax Sync. The functions of Queue and Sync are similar: Queue makes one Ajax call at a time and waits for its response to return before making another call. Sync makes multiple calls almost at the same time, but the response to the call is returned sequentially.

The problem of overloading is solved by controlling Ajax calls on the client side, and the way the response is sent back to the client is also controlled and regulated. Now you can make sure that you know the order in which the responses are returned to the client, so that you can write code based on the order of events. Let's take a look at how this plug-in works and how to use it in your code (see listing 7). Remember, this is only designed for 1% of Web applications, which have multiple Ajax calls, and the latter call is heavily dependent on the result of the previous call. This example is not an example of call interdependence, but it shows you how to use the plug-in (it is difficult to create a real example of the plug-in's application and make it easy to understand).

VarnewRow= "+" + "?"; $("# mailtable"). EveryTime (30000, "checkForMail", function () {/ / byusingtheAjaxQueuehere,wecanbesurethatwewillcheckformail / / every30seconds,butONLYifthepreviousmailcheckhasalreadyreturned. / / Thisactuallywouldbebeneficialinamailapplication,ifonecheckfor / / newmailtakeslongerthan30secondstorespond,wewouldn'twantthe / / nextAjaxcalltokickoff,becauseitmightduplicatemessages (depending / / ontheserversidecode) / / So,byusingtheAjaxQueueplug-in,wecanensurethatourWebclient / / isonlycheckingfornewmailonce,andwillneveroverlapitself. $.ajaxQueue ({url: "check_for_mail.jsp", success:function (data) {varmessage=eval ('('+ data+')'); if (message.iddistribution0) {varrow=newRow.replace ("?", message.id); rowrow=row.replace ("?", message.id); rowrow=row.replace ("?", message.to); rowrow=row.replace ("?", message.from); rowrow=row.replace ("?", message.subject) Rowrow=row.replace ("?", message.sentTime); $("# mailtabletbody") .prepend (row); $("# mailtable#" + message.id) .addClass ("mail_unread"). AddClass ("messageRow"); $("# mailtable#" + message.id+ "td"). AddClass ("mail"); $("# mailtable:checkbox"). AddClass ("selectable");})

Remember: if your application has multiple interdependent Ajax calls, consider using Ajax Queue or Ajax Sync.

The second example Web application

I'll use another widget to solve the three problems in this article and show and explain it before delving into its code. This 401k widget is no stranger, as you've seen it in previous articles (see the Resources section for links to these articles). This time, however, there is a subtle difference, because I added the widget twice on the same page. It is added to two different tables. This will bring several interesting places. Figure 3 shows this widget:

In this widget, I'm doing a few things. * is to calculate the sum of text fields and determine whether they are 100 or not. If their sum is not 100, I will show an error to the user indicating that they are not using the widget correctly. Second, I sort the options after each option gets input. In this way, the investment allocation of the percentage will always appear at the top of the table. This can be seen in figure 3, which sorts options by percentage. * to make it cooler, I added some stripes.

The HTML code used to produce this widget is surprisingly simple. Listing 8 shows this widget in detail.

S&P500Index Russell2000Index MSCIInternationalIndex MSCIEmergingMarketIndex REITIndex

Set up widgets with jQuery

The above short HTML introduces this directly, and this section focuses on how to set up widgets in jQuery, and all the code you need. You usually need to do this when you want to attach an event to a page element or when you need to add a class in certain cases. Sometimes it needs to go further. All the setup codes for these widgets are jQuery code.

I can provide a theory of role separation and let HTML designers and JavaScript programmers do their own work, but you may have heard this statement many times. I only add one other thing here, that is, "class decoration", which is used by many plug-in creators. Looking at the HTML code in listing 8, you can significantly change the functionality and appearance of the table simply by adding a percentSort class to the table. This is the goal of widget design, making adding and removing widgets as simple as adding classes to widgets.

Let's follow a few steps that I used to set up widgets with jQuery. By looking at these steps, you can see how the design pattern in listing 9 appears.

(document) .ready (function () {/ / thefirststepistofindallthetablesonthepagewith / / aclassofpercentSort.Theseareallthetableswewantto / / convertintoourwidget. / / Afterwefindthem,weneedtoloopthroughthemandtakesome / / actionsonthem / / Attheconclusionofthisblockofcode,eachtablethat'sgoingto / / beapercentSortwidgetwillhavebeentransformed $("table.percentSort") .each (function (I) {/ / eachtableneedsauniqueID,fornamespaceissues (discussedlater) / / wecansimplycreateauniqueIDfromtheloopcounter $(this) .attr ("id", "percentSort-" + I); / / withineachtable,let'shighlighteveryotherrowinthetable,to / / giveitthat "zebra" look $(this). Find ("tbody > tr"). Filter (": odd"). AddClass ("highlight") / / becauseeachtableneedstoshowthe "Total" totheuser,let'screateanew / / sectionofthetableinthefooter.We'lladdarowinthetablefooter / / todisplaythewords "Total" andaspanfortheupdatedcount. $("#" + $(this) .attr ("id") + "tfoot") .append ("Total%"); / / finally,let'saddtheCLASSof "percentTotal" tothespanwejust / / createdabove.We'llusethisinformationlatertodisplay / / theupdatedtotals $("#" + $(this) .attr ("id") + "tfootspan") .addClass ("percentTotal");}); / / nowthesecondstep,afterwe'vecompletedsettingupthetablesthemselves / / istosetuptheindividualtablerows. / / Wecansimilarlysortthrougheachofthem,takingtheappropriateactions / / oneachoftheminturn. / / Uponcompletionofthisblockofcode,eachrowineachtablewillbe / / transformedforourwidget$ ("table.percentSorttbody > tr") .each (function (I) {/ / getthenamespace (tobediscussedinthenextsection) varNAMESPACE=$ (this) .attr ("table.percentSort"). Attr ("id"); / / attachauniqueIDtothisrow.Wecanusetheloopcounter / / toensuretheIDisuniqueonthepage (whichisamustoneverypage) $(this) .attr ("id", "row" + I) / / now,withinthisrowofthetable,weneedtofindthetextinput,because / / weneedtoattachaclasstothem.Weutilizethenamespace,andalso / / findthe:textwithinthetablerow,andthenattachthecorrectclass $("#" + $(this) .attr ("id") + ": text") .addClass ("percent"); / / Finally,weattachauniqueIDtoeachofthetextinputs,andwedothisby / / makingitacombinationofthetablenameandtherowname. $("#" + $(this) .attr ("id") + ".cake"). Attr ("id", NAMESPACE+ "-" + $(this) .attr ("id"));}); / / Finally,becauseweknowweonlywantnumericalinputs,werestrictthetextentry / / tojustnumbers.Wemustdothisnow,becauseupuntilthispoint,thepage / / containednoelementswiththeCLASS "percent" $(".customers") .numeric ()

As you can see from this example, you can introduce a lot of functionality into HTML code through jQuery code. The benefits of this type of design are obvious. Similarly, it is also useful to follow role separation, code reuse, and so on. You'll also see this type of design in the widget plug-in, as it transforms simple HTML code into widgets for plug-ins. Most importantly, this is what you need to do here, which is to write a plug-in to turn a simple table into a sorted and summary table.

Remember: use as much jQuery code as possible to set up, and use HTML as little as possible.

Namespace

Perhaps the most difficult aspect of dealing with this type of design and jQuery is understanding namespaces. This example is good because it shows the problem in a very intuitive way. Writing jQuery code is very simple when you know all the ID and classes on the page. This is the design goal of jQuery. What happens when you don't know how many classes there are on the page, or when they start to repeat? In this example, you can see the problem directly, with two identical widgets! Everything is repeated. This seems to be regardless of the problems caused by namespaces; your widgets begin to interfere with each other and eventually fail to work properly.

The reason for this problem is that you only call $(".synchronization Total") and so on, ignoring which widget should be synchronized. Because there are multiple tables on the same page, the page has multiple instances of the percentTotal class. Of course, if there is only one table on the page, you can be sure that it is unique. But as pages become more advanced and components are reused more and more, this one-table assumption is no longer true. Some people will ask, "isn't it okay to use ID here?" This doesn't solve the problem: what ID are you going to give it? You cannot use "percentTotal" because it can lead to ambiguity.

You can't use "percentTotal-1" either, because it doesn't represent anything on the page. (the above numbers are, after all, arbitrary.) You can solve the problem by adding references to the tables that the page contains, such as "percentTotal-percentSort1", but this complicates the problem. JQuery has a super-complex but easy-to-use selection syntax that makes this hybrid naming pattern unnecessary. Why recreate what you already have? Let's use jQuery's selection engine to help you solve the namespace problem.

The core issue of this widget is to determine which widget the operation occurs in. When entering numbers into a text box, you can ask yourself, how does jQuery know which text box to enter? You add an event to the percentage class in your code, and you can reference it using $(this) within your code. This brings us to the next question: how does jQuery know which widget the problem is in so that you can update the correct percentTotal field? I don't think it's a simple thing. It's not easy. Although your code can add an event to each text box on the page with the percentage class, it is not appropriate to ignore the widget in which the event occurred.

The reason this problem boils down to a namespace problem is that the naming of the widget is not clear and can easily lead to problems. For the jQuery code to work, each name must be clearly defined within its own space, which gives rise to the term namespace. You must avoid writing code with duplicate names and implement that each widget is self-contained. You must be able to add multiple instances of the same widget on the same page while avoiding duplicate names. Most importantly, each widget is independent on the page.

There is no ready-made way to deal with namespace problems, so I'll show you my solution, which you can use in your own code or create a better solution by understanding the problem. The reason I like this code is that it is easy to use (only 1 line) and gives you some control over your own namespace. Look at listing 10.

/ / oureventisattachedtoEVERYinputtextfieldwithaCLASSof "percent" / / thismakesourcodelookgood,butcanleadtonamespaceissues $("table.percentSortinput.percent") .keyup (function () {/ / thissimplelinecanestablishanamespaceforus,bygettingtheunique / / IDattachedtoourtable (thetableisconsideredthe "container" for / / ourwidget.Itcouldbeanything,dependingonyourspecificcode.) / / WepasstheCLASSofourwidgettotheparents () function,because / / thateffectivelyencapsulatesthewidget varNAMESPACE= "#" + $(this) .keyup ("table.percentSort") .keyup ("id") / / withthenamespaceestablished,wecanusethejQueryselection / / syntaxtousethisnamespaceasourprefixforallofourremaining / / searches.Noticehowtheambiguityisremovedforoursearch / / byCLASSof "percent" and "percentTotal" / / Thissolvesournamespaceissues varsum=$ (NAMESPACE+ "input.percent") .sum (); vartotalField=$ (NAMESPACE+ ".aggregate Total")

So, with just one line of code, you can encapsulate the widget, preventing its functions from duplicating other instances of itself (or even other widgets that happen to use the same name for the ID or class). This type of coding is common in plug-in code. A well-written plug-in should take into account the namespace problem, while a bad plug-in ignores it. As you can see from this example, using namespaces in your code is also simple, and as the page becomes more complex, it can save you a lot of time. For this reason, I suggest you start thinking about namespaces in jQuery code now and use this solution when writing code.

Remember: when you start writing jQuery code, you usually start to include namespace solutions. You can use the above solution, or create your own solution. By adopting a namespace solution, even if the code becomes more and more complex, it does not cause the problem of name duplication.

Concluding remarks

This article provides some tips to help you turn good jQuery code into powerful jQuery code. JQuery is very easy to use (and a huge improvement on stand-alone JavaScript), so it's easy to write good jQuery code. Most developers write and run good jQuery code in a matter of minutes. But there is a difference between good code and strong code. Powerful jQuery code considers performance issues as pages become more complex. Powerful jQuery code can take into account the future direction of the page, rather than just seeing the current location. Powerful jQuery code is designed for the most complex applications, and then lets the application handle the simple information entered.

This article introduces five concepts to help you turn good jQuery code into powerful jQuery code.

The * concept is to use the bind () / unbind () method. These methods are useful for adding / removing events to page elements when you do not want to add events to your code during the life cycle of the page. These methods are important to improve performance when the page contains a large number of events, or are used in some user interfaces.

The second concept is to use the new feature live () / die () included in 1. 3. These functions allow you to make events dynamic, just like page elements. As Web applications contain more and more page elements, these functions allow code to grow as the page grows, which would not have been possible in previous releases. You want event handling to be as dynamic as page processing.

The third new feature is the AjaxQueue/Sync plug-in, which is used to regulate and control Ajax calls to the server to prevent them from exceeding the limit (from a client-side perspective). The plug-in can also be of great help when the order in which the responses of Ajax calls are returned is important.

The fourth concept is to write page setup code as much as possible in jQuery code. This makes it easier to write HTML and gain more control when setting up the page.

The first concept is to use namespace solutions in your code to avoid problems caused by duplicate function names of widgets. Each page element and widget should be self-contained and not interfere with other aspects of the page, and namespace solutions can prevent this problem.

These five steps are not difficult to achieve. In fact, four of these steps require only one line of code to be modified. However, it is most important to understand how to apply them in your code. Like everything, if it is not used correctly, it is not only not helpful, but also harmful. My advice is that when you write a page in jQuery code, apply these five steps as soon as possible. Every developer will tell you that taking advantage of features is part of the programming process. You don't want to redesign the entire Web application just because it got off to a bad start or changed some parts. Write code with the idea of writing powerful applications and follow these recommendations.

This is the end of the method of optimizing Web application in jQuery. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.