Extend $fn namespace in jQuery - javascript

This seems simple but I cannot figure how to extend the $fn namespace.
JS:
(function ($) {
$.fn.myorg.level1.level2.myFunction = function (usettings, params) {
return this.each(function () {
//do work...etc
});
};
} (jQuery));
$("bla").myorg.level1.level2.myFunction(...);
How do I define the namespace chain so I can write functions like above?
The example I have given is very simple, the namespace isn't expected to be very deep however, I need to be able to extend and add functions...etc to my namespace tree at will. I don't want to redefine the tree for each addtional function/level I add.
I haven't seen any good examples. If I stay at the $fn level it's easy, but that doesn't make my code as clean and extensible as I need it.
If what I am asking for is not possible, what is the correct approach?

Epascarello hinted at this, but I'm guessing that the previous objects aren't defined.
console.log($.fn.myorg); // undefined
$.fn.myorg.level1 = function(){}; // TypeError: Cannot set property 'level1' of undefined
But if we define things first:
$.fn.myorg = $.fn.myorg || {}; // if this object doesn't exist, create an blank object
console.log($.fn.myorg); // object
$.fn.myorg.level1 = function(){};
console.log($.fn.myorg.level1); // function

Related

module pattern setters that has methods

EDIT:
Everything is working as I expected. It was just an error calling the template method. I mistyped a () so I was trying template.method instead of template().method;
Anyway, if somebody would like to explain me if this is a valid design pattern or if I should go in a different way I will be definitively very grateful.
I read about the module pattern and I'm trying to implement it in some of my projects. The problem is that, in my opinion, I'm twisting it too much.
I'm inspired by the google apps script style where many objects returns other objects with methods and so on and they pass arguments.
something like
object.method(var).otherMethod();
What I want to achieve is a method that receives a parameter, sets an internal variable to that parameter and then returns an object with methods that uses that variable. Here is a minified version of the code that does not work:
var H_UI =(function (window) {
var selectedTemplate,
compileTemplate = function(){},
parseTemplateFields = function(){};
//template subModule. Collect: collects the template fields and returns a JSON representation.
var template = function(templateString){
if(templateString) selectedTemplate = templateString;
return {
getHtml:function(){ return compileTemplate( parseTemplateFields( selectedTemplate ) ) } ,
collect:function(){
.. operating over selectedTemplate ...
return JSON.stringify(result)}
} };
return {
template:template
};
})(window);
If I remove the line :
if(templateString) selectedTemplate = templateString;
and replace selectedTemplate with the parameter templateString in the methods of the returned object it works as expected. I know that I cant create a set() method in the returned object and use it like this
H_UI.template().set(var)
But I find it ugly. Anyway I think that I'm messing things up.
What is the best way to construct this?
If you want H_UI.template() creates a new object every time you call template() on it, your solution does not work. Because the variable selectedTemplate is created only once when the immediate function is called.
However if your intent is this your solution works fine. (variable selectedTemplate is shared for all calls to template()).
But if you want to every call to template creates a new object. Please tell me to write my idea
Is this a valid design pattern or if I should go in a different way
Yes, enabling chaining is definitely a valid design pattern.
However, if your template() method returns a new object, that object and its methods should only depend on itself (including the local variables and parameters of the template call), but not on anything else like the parent object that template was called on.
So either remove that "global" selectedTemplate thing:
var H_UI = (function () {
function compileTemplate(){}
function parseTemplateFields(){}
// make a template
function template(templateString) {
return {
getHtml: function(){
return compileTemplate(parseTemplateFields(templateString));
},
collect: function(){
// .. operating over templateString ...
return JSON.stringify(result)
}
}
}
return {template:template};
})();
or make only one module with with a global selectedTemplate, a setter for it, and global methods:
var H_UI = (function () {
var selectedTemplate;
function compileTemplate(){}
function parseTemplateFields(){}
return {
template: function(templateString){
if (templateString)
selectedTemplate = templateString;
return this; // for chaining
},
getHtml: function(){
return compileTemplate(parseTemplateFields(selectedTemplate));
},
collect: function(){
// .. operating over selectedTemplate ...
return JSON.stringify(result)}
}
};
})();
The difference is striking when we make two templates with that method:
var templ1 = H_UI.template("a"),
templ2 = H_UI.template("b");
What would you expect them to do? In a functional design, templ1 must not use "b". With the first snippet we have this, and templ1 != templ2. However, if .template() is a mere setter, and every call affects the whole instance (like in the second snippet), we have templ1 == H_UI and templ2 == H_UI.

javascript: constructor function vs revealing module pattern for single use

I have come to understand that constructor functions can be instantiated to create new objects in javascript which has its own _proto_ property and also giving the property 'prototype' to the constructor function.
function MyController() {
var controllerName = 'initialcontroller';
function init() {
console.log(controllerName);
}
this.init = init;
}
Here, init can be called like this:
var mycontroller = new MyController();
mycontroller.init();
Supposing I am only instantiating only once and never again, isn't this an overkill if I don't intend to use all the prototype properties being provided by the MyController.prototype ?
Question: Instead, can i not code like this using the revealing module pattern?
var myController = function() {
var controllerName = 'initialcontroller';
function init() {
console.log(controllerName);
}
return {
init : init
}
}();
Here, init can be called like this:
myController.init();
In this case, if I try to access any property inside myController that is not present, the javascript engine won't try to find whether the property exists anywhere in the prototype chain, thus saving my time.
Or is there any other advantages of instantiating a function that i am overlooking?
If you simply want a "singleton"-like object with some methods and other properties, you could just use an object literal to simplify things even more:
var myController = {
init: function (foo) {
// do something with foo or whatever
}
}
myController.init("bar");
Or - if you need some "private" internal state, use the regular revealing module pattern:
var myController = (function () {
var internal = "i am private";
return {
init: function () {
// blah blah
}
};
}());
myController.init();
About the prototype lookup time: Yeah, theoretically, the lookup traverses up the prototype chain when you're trying to access a non-existing property. Theoretically, this might be a tiny bit faster for plain ol' Object instances that have "no" specific constructor. In reality, this performance impact should be quite negligible. Don't attempt to optimize here unless you REALLY need it. :)

Overriding a function without removing static properties

If I have a function like this:
function a() {
console.log('a');
}
and then assign a static property like this:
a.static = 'foo';
But say I want to override the function with another function like this:
var old = a;
a = function() {
console.log('new');
old.call(this);
};
a.static // undefined
Since I assigned a new function to a, it’s static properties are lost. Is there a neat way to keep the static properties without looping and manually copying them?
Update:
Here’s a real world scenario: In Bootstrap jQuery plugins, the author assigns defaults to the property function like this:
$.fn.modal = function() {
// some code
};
$.fn.modal.defaults = { // some object };
So if I want to "extend" the prototype I would normally do:
var old = $.fn.modal;
$.fn.modal = function() {
// do my thing
old.apply(this, arguments);
}
But that would make
$.fn.modal.defaults === undefined
This will break the functionality, because the defaults are lost. I was wondering if there a sneaky way in javascript to change only the function without losing the static properties.
No, you cannot do this. Replacing the object (function) always takes any properties with it.
There are two solutions here, and both involve transferring the properties from the old object to the new one.
The first (recommended) approach is to copy the properties, which can be done conveniently with $.extend:
$.fn.plugin = $.extend(function() { ... }, $.fn.plugin);
The second option would be to dynamically set the prototype of the new function to be the old function. For example, in some browsers this would work:
var f = function() { ... };
f.__proto__ = $.fn.plugin;
$.fn.plugin = f;
However this is non-standard and might give rise to complications; don't do it.

organizing js prototype methods

after experimenting with js's prototypal inheritance i've found that i'm not wild about the idea of having to declare my object's methods outside of the object:
function obj(){
this.averyday='i\'m shuffle\'n';
this.gibmo='dinero';
this.pullOut='that\'s what she said lol';
}
obj.prototype.alertProp=function(){
alert(this.averyday);
}
obj.prototype.alertProp2=function(){
alert(this.gibmo);
}
so i came up with a way to organize my methods into one namespace
obj.prototype.m={
//i'm passing in the object instance so the mathods can have access to it's properties
alertProp:function(that){
alert(that.theObj.everyday);
},
alertProp2:function(that){
alert(that.myObj.gibmo+' '+that.myObj.someVal); // alerts "dinero some other value to be use "
}
}
var myobj = new obj;
then to use i just call the method and pass in the objects instance(if the method needs to modify the object's properties)
myobj.m.alertProp({theObj:myobj,someVal:'some other value to be use'}) //alerts "i'm shuffle'n"
so here are some pros that i've noticed:
PROS:
1) organizes the methods into one centralized area.
2) accesses the "prototype" of an object only once(in effect uses less code).
3) seems more readable(at lease to me).
CONS:...this is where i need you'alls help, does anyone see anything wrong with doing it this way? any performance issues or anything wrong with the pros i've outlined etc...?
also does anyone see any other pros that i may not be seeing or that aren't apparent?
I find it a little bit complicated, this is how I like to do it:
MyObject = function (options) {
this.init(options);
};
MyObject.prototype = {
/**
* Documentation
*/
variable1: null,
init: function (options) {
// do something with options.
},
alertVariable: function () {
alert(this.variable1);
}
};
So you don't have to worry about sending extra parameters, you just call it.
----------------------------EDIT---------------------------------
Well, I don't know if I got it right, but after some reading I believe this would "fixing the constructor" mean. If I create an object like this:
Foo = function () {
// Do something
};
Then Foo.prototype.constructor == Foo, as one would expect.
The problem with my method (thanks Raynos) is that when I'm doing this:
Foo.prototype = {...};
I'm overwriting all of Foo's prototype, so that Foo.property.constructor != Foo, and that is not what we would expect! Instead of that we have that Foo.property.constructor == Object.prototype.constructor.
So, how we fix it?
Foo.prototype = {
constructor: Foo, // <-- FIXED!
...
};
Ta da!
(this helped a lot: http://beej.us/blog/data/javascript-prototypes-inheritance/ )

Tips for an intermediate javascript programmer to write better code

So I'm a fairly decent javascript programmer and I've just recently finished working on a fairly big web application that involved writing quite a bit of javascript. One of the things I can across when I was debugging my script was that there were some namespace conflicts with my various global variables I used throughout my script. Essentially, my javascript file was structured as such:
global var a
global var b
global var c
function1(){}
function2(){}
function3(){}
with a jQuery document on-ready function to bind various events to buttons in my html and call my functions as event handler callbacks.
Some people recommended encapsulating my entire script in one gigantic function to prevent any scope-related errors. I couldn't quite figure out exactly what that would entail. Any tips are appreciated as I am about to create another web app that will involve quite a bit of AJAX page loads to avoid browser refreshes and DOM manipulation bound to various events. Thanks!
I recommend reading the jQuery plugin authoring guide (I also recommend you consider using jQuery if you are not)
http://docs.jquery.com/Plugins/Authoring
BTW this been asked many times (not a criticism for re-asking)
jQuery: Global Variable Namespace Problem
Avoiding polluting the global namespace with javascript dependencies
JavaScript Namespace
I also highly recommend you read about jQuery live plugin for register DOM events(I guess its built-in now):
http://api.jquery.com/live/
(this will minimize the nasty need for state management of unbinding and rebinding your DOM nodes).
A similar alternative to Michael's and nnnnnn's version is to do
var YourApp = {
a: 1234,
b: 5678,
function1: function () {
},
etc
};
YourApp is the only global var and its properties can be accessed like
YourApp.function1();
or
YourApp.a;
I like wrapping the contents of each file inside an anonymous function. You can then pass window to this as a parameter and selectively choose what to export from each file.
(function(exports) {
var MyClass = function() {
};
MyClass.prototype.method = function() {
};
// this won't be visible outside this file
var helperFunction = function() {
};
exports.module = exports.module || {};
exports.module.MyClass = MyClass;
})(window);
Also, you can structure it in the following way to use this as the global object instead, if that appeals more to your coding style:
(function() {
this.Thing = function() { };
}).call(window);
I expect to get downvoted from OO purists, but...
A very simple solution to the namespace collisions is to place your variables and functions into a class, even if it doesn't have a working constructor or perform any internal processing of its own.
function YourApp() {} // empty constructor...
YourApp.a = 1234;
YourApp.b = 5678;
YourApp.function1 = function() {};
YourApp.function2 = function() {};
function YourOtherApp() {} // empty constructor...
YourOtherApp.a = 1234;
YourOtherApp.b = 5678;
YourOtherApp.function1 = function() {};
YourOtherApp.function2 = function() {};
// Then you call it like:
YourApp.function1();
// And you have no more namespace collisions with other globals
The quickest first step based on what you have done in the past with lots of global variables and functions is to simply take all of those and make them properties of a single object. That single object is declared as a global variable, but it is your only global variable and is effectively your new namespace and thus you only have to worry about one name potentially clashing with other libraries.
So relating that directly to the example you gave with a, b, etc:
var SNS = {}; // create some namespace object
SNS.a = "something";
SNS.b = "something else";
SNS.c = 17;
SNS.method1 = function(x) {
alert(SNS.a + x);
};
SNS.method2 = function() {
SSN.method1(12); // call another function
};
SNS.SUB = {};
SNS.SUB.property1 = "sub namespace prop 1";
SNS.SUB.method1 = function() {};
// etc.
My example uses 'SNS' for 'some namespace'; I'm sure you can immediately see how that would be pretty easy to apply to the project you just finished. You can probably also see the disadvantage that for your methods to refer to each other and to your variables you have to prefix them all with the name of your object. If you have sub namespaces that gets worse. Fortunately there are ways around that, but I'm declaring them outside the scope of this answer.
Having said all that, something for you to read up on (Google) is the "revealing module pattern" - will help you go a bit more OO (if that's what you want).
A really in-depth answer to your question can be found here: http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/
Further reading:
http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth

Categories

Resources