My Favorite jQuery Plugin Template(kolodny.github.io)
kolodny.github.io
My Favorite jQuery Plugin Template
http://kolodny.github.io/blog/blog/2013/12/27/my-favorite-jquery-plugin-template/
10 comments
Neat. I also like this one (Coffeescript): https://gist.github.com/rjz/3610858
I'm not a huge fan of the double wrap of anonymous functions. The inner one seems entirely superfluous unless you're adding multiple plugins in one file and, I think, makes the code a little harder to read since you have to look at the invocation of the function to get all the information you need about it.
It seems a lot clearer to simply declare `var pluginName = "borderize";` at the top of the function than to pass it in. Granted, that does add 6 characters to the total length of the file.
It seems a lot clearer to simply declare `var pluginName = "borderize";` at the top of the function than to pass it in. Granted, that does add 6 characters to the total length of the file.
Double wrapping is necessary for closure compiler to collapse variable names.
Well I plan on using this for multiple plugins in that same iffe. I also like that I'm able to copy/paste it as a block inside other jQuery blocks.
"I plan on using this for multiple plugins in that same iffe"
Isn't a little bit inconvinient, talking about modularity, will you be the only one using those plugins?
Isn't a little bit inconvinient, talking about modularity, will you be the only one using those plugins?
These days I'd prefer a plugin template that doesn't infect the jQuery namespace by default (and is AMD compatible) so I can use it with a module loader:
Edit: I guess such a thing is not really a 'jQuery plugin' but a 'module that depends on jQuery'.
var borderize = require('jquery.borderize');
...
borderize('div');
Edit: I guess such a thing is not really a 'jQuery plugin' but a 'module that depends on jQuery'.
Why not:
options = $.extend(true, {}, defaults, options);
Because I didn't think of it :)
Actually that's better because if one of the options is an object I wouldn't have to worry about accidentally changing a propery because this does a deep copy.
I've updated the post, thanks.
Actually that's better because if one of the options is an object I wouldn't have to worry about accidentally changing a propery because this does a deep copy.
I've updated the post, thanks.
Cool stuff! This reminds me a lot of jQuery Boilerplate: https://github.com/jquery-boilerplate/jquery-boilerplate/blo...
Personally, I find the "that" variable to be a little confusing. A developer looking at the code might wonder whether "that" is the plugin, a DOM element, or something else. To make the code a little clearer, you could use something like "elem" to represent the element on which the plugin has been called, and "plugin" to represent the plugin itself.
Happy coding!
Personally, I find the "that" variable to be a little confusing. A developer looking at the code might wonder whether "that" is the plugin, a DOM element, or something else. To make the code a little clearer, you could use something like "elem" to represent the element on which the plugin has been called, and "plugin" to represent the plugin itself.
Happy coding!
That's a good point. I've updated the post to use `elem` and `$elem`
Thanks
Thanks
Save a few bytes.
;!function($){
...
return this.each(function($elem, elem){
$elem = $(elem);
...
});
...
}(jQuery);Ho boy not this again...
https://github.com/twbs/bootstrap/issues/3057
https://github.com/twbs/bootstrap/issues/3057
How does anyone consider this sane javascript? Is this what the community has been reduced too?
What is the problem with `$this = $(this)` ?
You used `that` but I didn't get that.
Once I set up an alias for `this` I try to only use that from then on to be consistent. The reason I do that in the first place is in case I need to pass it to a callback, I can just use the alias and don't have to worry about when `this` will be the global object
If you minimize your javascript, `that` can be minimized, `this` cannot.
I find the pluginName parameter excessive.
[deleted]