Fluid / JS / best practices / code templates

Noah Botimer botimer at umich.edu
Fri Sep 12 14:50:08 UTC 2008


Colin,

This is a wealth of good info and style.  The Unit page/template  
catches everything I was especially interested in.  Thanks to all for  
the great work!

Thanks,
-Noah

On Sep 11, 2008, at 6:00 PM, Colin Clark wrote:

> [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:
>
> http://wiki.fluidproject.org/display/fluid/Fearless+JavaScript 
> +Workshop
>
>> 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 () {
>         doSomething();
>     }
>
>     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.
>
> http://www.jslint.com/
>
>> 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  
> space.
> (function ($) {
>
>   // Code goes here.
>   fluid.uploader = function () {...};
>
> })(jQuery);
>
> We're also planning to use this technique in a future release of  
> Infusion to provide support for multiple simultaneous version of  
> our code.
>
>> 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:
>
> http://wiki.fluidproject.org/display/fluid/How+to+Define+a+Unit
>
> 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
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
>
>




More information about the fluid-work mailing list