Fluid / JS / best practices / code templates

Colin Clark colin.clark at utoronto.ca
Thu Sep 11 22:00:16 UTC 2008

[Noah emailed me off list with some JavaScript questions, but kindly  
agreed to let me respond publicly]

Hey Noah,

On 10-Sep-08, at 2:21 PM, Noah Botimer wrote:

> Hey Colin,
> I figured I'd just ping you rather than scour for outdated stuff  
> buried in PPTs...
> You mentioned in France that you had a few code patterns that were  
> awesome ideas for X reason or other.  I'm especially keen on picking  
> up someone else's treatment for packages/"classes" and handling of  
> "this".

Yeah, this material was part of the Fearless JavaScript presentation  
that Nico, Eli and I gave in Paris. In case you do need to dig into  
the slides, they're located here in the wiki:


> I notice you recommend "that" for the persistent self-reference, and  
> I kind of like it -- I'm not sure if I like it more or less than  
> "me", but consistency with Fluid code is something I can dig.  I'm  
> also not sure if I even set it up right in my code.  I still find  
> surprises with scoping occasionally (usually because I forgot "var")  
> and generally distrust my level of JS enlightenment, so a template/ 
> pattern would be awesome.

I do recommend avoiding the slipperiness of the "this" pointer in  
JavaScript by referring to your own stable reference to the current  
instance. The specific name doesn't matter to me at all. Call it "me,"  
"self," "foo," or whatever you prefer. The only reason we chose to  
call it "that" was because it seemed simultaneously funny and obvious.  
It's also the convention that Douglas Crockford uses, so it has a  
chance of being recognizable to others.

Here's how I set it up:

// Creator function instead of a constructor with the new keyword
var myCoolThing = function (lots, of, args) {
     var that = {}; // Stable pointer to the current instance

     // public methods here.
     that.publicMethod = function () {

     return that; // Don't forget to return your new instance.

The ability to omit var is really the worst bug in the language, so I  
can sympathize the kind of scoping accidents. The language should  
thrown an error in this case, but it doesn't. In order to avoid these  
kinds of common mistakes, I often use JSLint to scan my code. It fills  
in all the things I miss about not having a compiler.


> I also like passing the skeleton object to the constructor by the  
> same name as within the package -- it feels more explanatory than  
> the this.whatever = function() syntax.  And the insulation of jQuery  
> vs. $ is a sweet hack.

Yeah, the use of an anonymous closure wrapping your code is a really  
awesome way to ensure you've got your little scope, independent of  
everyone else's code. And it's a nice way to provide convenient  
aliases. Here's how we tend to do it:

fluid = fluid || {}; // Define the namespace we're part of.

// Define an anonymous closure which will serve as our own private  
(function ($) {

   // Code goes here.
   fluid.uploader = function () {...};


We're also planning to use this technique in a future release of  
Infusion to provide support for multiple simultaneous version of our  

> Do you have some current links to this stuff handy?

I have a page in the wiki documenting a few of our recommended  
techniques, including a little template you can cut and paste:


But you're reminding me that I should probably document more of the  
Fearless JavaScript material in the wiki as well. It's something  
Anastasia and I will work on together for Fluid user manual. I'd also  
really like to make a little plugin for Aptana/Eclipse for creating  
new objects.

Let me know if this is at all helpful. I'd love feedback or ideas  
about techniques you'd like to know more about. Or if you're totally  
confused by it, that's helpful to know too. Or techniques you like to  
use. :)


Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto

More information about the fluid-work mailing list