Jump to content

the module pattern in JS


skaterdav85

Recommended Posts

I found a good article on namespacing in JS, and one of the approaches to achieve this was by using the module pattern which uses a closure. I understand the syntax, but what I am having trouble wrapping my head around is the need for private variables in JS. Can someone think of a scenario in which you'd want to make something private?http://javascriptweblog.wordpress.com/2010...-in-javascript/

Link to comment
Share on other sites

That's a great article! Thanks for posting it! :)There are certainly applications for private variables. I can't think of any specific examples right now, but sometimes you need to have variables within a namespace (or class as I like to refer to them) that you don't necessarily need outside of that namespace.EDIT:Ah, just thought of an example. I wrote a script for a custom dialog box. Within the namespace/class/object (whatever you want to call it) I use variables to reference various div elements. Outside of the CustomDialog class, I don't care what those variables/references are, but inside I use them to style and populate those elements.

Link to comment
Share on other sites

I found a good article on namespacing in JS, and one of the approaches to achieve this was by using the module pattern which uses a closure. I understand the syntax, but what I am having trouble wrapping my head around is the need for private variables in JS. Can someone think of a scenario in which you'd want to make something private?http://javascriptweblog.wordpress.com/2010...-in-javascript/
That's a great article! My company uses the module pattern a lot for their libraries, and we're starting to write our applications that way as well, which seems to lend itself to unit testing much more, which we're also moving too. In our situation, when there is the chance of multiple libraries being included by a single application, the chance of collisions increase, and maintaining scope becomes much more of an issue. We combine the two, in such a way that it would look like this:
myApp = {};(function ($) {    $.services = {};  $.user = {};  $.device = {};  $.config = {};})(myApp);

Link to comment
Share on other sites

Hypothetically, a person who develops an object for use in his own applications does not need to distinguish private data from public data. You should be able to look at your own code and know what to mess with and what not to mess with.But in a situation where multiple programmers are working on separate modules for a single app, or for reuse in an arbitrary number of apps, it becomes harder and time consuming to look at a class and figure out what should be messed with and what should not. Keeping certain variables private, and exposing only the ones an application should be modifying, prevents a lot of problems.thescientist has also mentioned the problem of collisions. This becomes especially acute if you develop modules/libraries as a 3rd-party developer, like jQuery etc. People want their modules ready to go out of the box. They do not want to accidentally klobber data that was never meant for them anyway. If all your properties were public, but you only documented the properties you expect your clientele to use, it would be very easy for your clientele to re-prototype your class (create a "subclass"), and add "new" properties that actually overwrite existing properties, inadvertently breaking the object. Data like that should be private.

Link to comment
Share on other sites

Hypothetically, a person who develops an object for use in his own applications does not need to distinguish private data from public data. You should be able to look at your own code and know what to mess with and what not to mess with.But in a situation where multiple programmers are working on separate modules for a single app, or for reuse in an arbitrary number of apps, it becomes harder and time consuming to look at a class and figure out what should be messed with and what should not. Keeping certain variables private, and exposing only the ones an application should be modifying, prevents a lot of problems.thescientist has also mentioned the problem of collisions. This becomes especially acute if you develop modules/libraries as a 3rd-party developer, like jQuery etc. People want their modules ready to go out of the box. They do not want to accidentally klobber data that was never meant for them anyway. If all your properties were public, but you only documented the properties you expect your clientele to use, it would be very easy for your clientele to re-prototype your class (create a "subclass"), and add "new" properties that actually overwrite existing properties, inadvertently breaking the object. Data like that should be private.
So what happens if a new property is added and it shares the same name as a private property? I guess, more specifically, do private properties actually create properties of an object or are they just scoped variables? In PHP, if you declare a private property and try to access it using $obj->privateProp you'll get an error saying you can't access the private property. Is it similar behavior in JavaScript, or do private properties simply not "exist"? (Ie, obj.privateProp is undefined?)
Link to comment
Share on other sites

That's a great article! My company uses the module pattern a lot for their libraries, and we're starting to write our applications that way as well, which seems to lend itself to unit testing much more, which we're also moving too. In our situation, when there is the chance of multiple libraries being included by a single application, the chance of collisions increase, and maintaining scope becomes much more of an issue. We combine the two, in such a way that it would look like this:
myApp = {};(function ($) {    $.services = {};  $.user = {};  $.device = {};  $.config = {};})(myApp);

So looking at your example, I think it is the same as Dynamic Namespacing as mentioned in the article. Does your company use external JS libraries within the module pattern, or are you guys basically creating your own JS library from scratch that contains various modules? Do developers use the module pattern with a library like jQuery like this?
var myApp = {};(function(context) {	var id = 0;	context.next = function() {		//jQuery code here	};	context.reset = function() {		//jQuery code here	}})(myApp);

The benefit I can see here would be that myApp would be a custom object with the power of jQuery inside it, for whatever you may need jQuery for, such as cross browser AJAX or animation effects.Or does jQuery provide you with syntax that allows you to not use the module pattern? I've done plenty of jQuery, and I don't see where I could use the module pattern. I feel like I can create a self containing unit/module simply by using the triggering element to merely trigger a custom event (which you can easily create in jQuery), and have the custom event put the spotlight on the element being acted upon. A good example of this can be found here. What do you think?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...