Should You Use the ‘var $this = $(this);’ Syntax in jQuery?

The other day I tweeted that I

May succumb to this this syntax: var $this = $(this);*

May succumb to this this syntax

Click image to see original Facebook thread

Because I use Hootsuite and it’s a simple button push, I also posted it to Facebook. George Winters saw it there and wondered what I meant.

I was referring to a common jQuery coding practice.

var $this = $(this);

In the past, my answer on whether this practice was useful or necessary has always been “no”. I tend to use the convention of naming my variables like this:

var thisTermId = $(this).attr("a9");

and I’ve felt that this was enough “this” stuff. (Yes, this post is going to have a lot of this this stuff in it.)

So why do we care?

In this example, I’m parsing out the results form a call to the TaxonomyClientService GetChildTermsInTerm operation. (More on this in a later post.) We get back a text representation of the XML which ends up looking like this after some conversions:

<TermStore>
  <T a9="988b1b74-3b87-4f40-a6ee-066e592fbe89" a21="false" a61="0" a1000="227">
    <LS>
      <TL a32="Cereal" a31="true"/>
      <TL a32="Breakfast Treat" a31="false"/>
      <TL a32="Grains" a31="false"/>
      <TL a32="Bowl of breakfast" a31="false"/>
    </LS>
    <DS/>
    <TMS>
      <TM a24="d8110aa1-d8c2-4e0f-8a99-7e82db8a32dd" a12="Breakfast Foods" a40="" a17="true" a67="" a45="988b1b74-3b87-4f40-a6ee-066e592fbe89"/>
    </TMS>
  </T>
  <T a9="b793fd58-45b7-4540-9098-140815864900" a21="false" a61="0" a1000="291">
    <LS>
      <TL a32="Bacon" a31="true"/>
      <TL a32="Manna" a31="false"/>
      <TL a32="Rackley's Favorite Food" a31="false"/>
    </LS>
    <DS/>
    <TMS>
      <TM a24="d8110aa1-d8c2-4e0f-8a99-7e82db8a32dd" a12="Breakfast Foods" a40="" a17="true" a67="" a45="b793fd58-45b7-4540-9098-140815864900"/>
    </TMS>
  </T>
  ...
</TermStore>

The data is pretty well organized, but I need to get it into an array so that I can use it in my application. To do this, I use jQuery selectors and .each() logic to iterate through the data, much like C# folks use enumerators.

In jQuery, when you use a selector, you can refer to the matches with $(this). Here’s a simplified version of the code I’m using:

$($termsXML).find("T").each(function() {
  var thisTermId = $(this).attr("a9");
  var thisTermName = $(this).find("TL[a31='true']").attr("a32");
  ...
});

In the example, I’m finding all of the elements (terms) in the $termsXML jQuery object and then parsing out two of the attributes inside them. I’m using $(this) in two different places (and in the actual code, many more places). Many JavaScript developers would do this instead:

$($termsXML).find("T").each(function() {
  var $thisTerm = $(this);
  var thisTermId = $thisTerm.attr("a9");
  var thisTermName = $thisTerm.find("TL[a31='true']").attr("a32");
  ...
});

There are a few benefits:

  • $(this) is only evaluated once (minor efficiency)
  • You can use a more descriptive name for $(this). I’m using $thisTerm above because it’s a taxonomy term.
  • By preceding the variable name with the $ sign, you’re reminding yourself that it’s a jQuery variable, not just a plain old JavaScript variable.

This all is really up to you. JSLint and JSHint don’t care whether you do this or not, but your code may be more readable over time. Whatever conventions you decide to follow, the more important thing is that you remain consistent over time. I’ve not used the $this syntax before and if I start doing it selectively in SPServices, for instance, I’ll have a tougher time maintaining it.


* I love playing with words like that. Check out this great picture I saw on Facebook the other day. But I digress…ship-shipping ship

SPServices 2013.01 Is Underway – Learnings Ensue

I’ve started really cranking on the new version of SPServices and I’m having a blast, as usual. I’ve learned a few things already, and I thought I’d capture them in a post.

“use strict”;

Just gotta do it. I balked at implementing this previously, as it kept hating my code. Well, it hated my code for a reason. "use strict"; makes you fix some pretty dumb mistakes, and I had quite a few of them. SPServices ran just fine with those mistakes, but by implementing "use strict";, they aren’t even there anymore.

If you want to understand why "use strict"; is a good idea with jQuery, read John Resig’s post ECMAScript 5 Strict Mode, JSON, and More.

JSLint vs. JSHint

JSHintAs part of my refactoring and housecleaning. I went to run SPServices through JSLint as I usually do. It seems that Douglas Crockford, godfather of JavaScript and author of JSLint, has introduced what amounts to either an annoying new feature or a bug into JSLint. I saw the message “Use spaces, not tabs.” on so many lines that JSLint only was making it through about 1% of my code before giving up.

There’s a post over on StackOverflow called New JSLint errors “use spaces, not tabs” and “unsafe character” wherein someone has tracked down what’s going on. I like using tabs in my code, so I took the hint and the advice in the post and headed over to JSHint instead.

It turns out that JSHint does some nice things that JSLint doesn’t do, anyway. Each message shows the line number as a link which takes you into the code at the proper spot to fix it right there. With JSLint, I was always copy/pasting back and forth to SharePoint Designer to make my fixes. JSHint also color codes your code in the edit window so that you can really do editing. Very nice. The only drawback is that JSHint throws an error when I try to run it in IE9, but I’m fine with working in Firefox.

Refactoring

Every single time I go through SPServices, I do a lot of refactoring. I’m a learning human, and each time I know more (at least I like to think I do) about good coding practices than the last time. Sometimes I really want to slap myself up side the head seeing what I did in some of my earliest efforts. I’m taking this opportunity to refactor things yet again, creating many more complex objects to store things than I had originally. This is a good thing, not a complicating thing, as it will make the code far more manageable and readable over the long haul. (Yes, there is a long haul. SPServices still has a good number of years in it, IMO.)

I’m also taking advantage of some of the SharePoint 2010 context information which is available in JavaScript variables (if we’re in 2010, of course, with nice fall back for 2007). Thanks to John Liu’s post SharePoint – JavaScript current page context info which gave me the impetus for this.

Version Numbers

You may have noticed that I’ve switched my version numbering scheme. I have been confusing myself with the version numbers over the last year or so. On one level I wanted to sort of align with the jQuery version numbers, and on another I was being coy and avoiding ever getting to version 1.0. (I’m asymptotic in my tendencies.)

With this version, I’ve switching the versing scheme altogether. This next version will be 2013.01, meaning the first version in 2013. It moves things away from the jQuery alignment and still is an increasing function, so it should make everyone happy. Except the people who will complain about it.

OK, enough chit chat. Back to work. Mark Miller and I are working on some magic and hijinks for his keynote next week at SPTechCon in San Francisco. Hope to see you there!