Comments on: Helpful JavaScript Design Patterns

By: Link Dump – November 23, 2012 Edition | Wern Ancheta

Link Dump – November 23, 2012 Edition | Wern Ancheta — Fri, 23 Nov 2012 13:52:22 +0000

[...] SourceURL: http://blog.newrelic.com/2012/10/09/helpful-javascript-patterns/ [...]

By: Meine Lesezeichen vom 27 September bis 12 Oktober : Casa Rock!

Meine Lesezeichen vom 27 September bis 12 Oktober : Casa Rock! — Thu, 15 Nov 2012 21:28:41 +0000

[...] Helpful JavaScript Patterns | New Relic blog [Tags: tips patterns javascript ] [...]

By: David Morrow

David Morrow — Tue, 06 Nov 2012 23:46:17 +0000

thanks for the update,
I like your pattern very much. I think the phrase “dependency injection” sums up what makes it so appealing.

Thanks for sharing this, this will make it into my snippets.

By: Greg

Greg — Mon, 22 Oct 2012 14:45:34 +0000

Sure thing, a simple example without using libraries may look generally like this:

window.MyApp = (window.MyApp || {});


MyApp.MyUtils = (function() {

	return {

		doHandyThing1: function() {},

		doHandyThing2 function() {}

	};

}());
MyApp.MyModule = (function( utils ) {
	var privateValue = "Encapsulated value. No one else can touch this.";
	var ModuleExport = function() {

		// Do constructor stuff.

		utils.doHandyThing1(); // << Take advantage of imported utilities!

	};
	ModuleExport.prototype = {

		publicValue: "Anyone can change this.",

		publicMethod: function() {

			// Anyone can call this.

		},

		getEncapsulatedValue: function() {

			// Anyone can call this to GET the encapsulated value.

			// However, nothing else can SET the encapsulated value.

			return privateValue;

		}

	};
	// Export a single instance of our module:

	return new ModuleExport();

}( MyApp.MyUtils ));

The key concept here that differs from your proposed module pattern is inversion of control: MyUtils and MyModule are two separate modules, and therefore, neither should be aware of each other within the application superstructure. While we could technically reference “MyApp.MyUtils.doHandyThing1″ from within MyModule, this violates the rule of modules being self-contained and ignorant of what’s outside of them. To loosely couple this relationship, MyApp.MyUtils is provided once in the MyModule scope invocation (final line of code), at which time it becomes available as a local variable within the MyModule scope. This relationship of dependency injection enforces encapsulation, keeping modules easier to manage and test. Frameworks such as Require.js are designed to automate this loosely coupled dependency management.

By: David Morrow

David Morrow — Tue, 16 Oct 2012 15:52:09 +0000

Thanks for your comments.
The above patterns i shared on the post are simply patterns i find myself using often that work well for many situations.
I’d love to see a gist of the pattern you are referencing, and I could possibly comment on it or even learn something myself.
- Dave

By: Greg

Greg — Mon, 15 Oct 2012 00:58:14 +0000

With all due respect to your definition of the module pattern; it seems incomplete as you portray it. Mind you, the term “module” is ambiguous, and therefore somewhat speculative. While your implementation publishes an object with a public API and encapsulated internals, both of which are important aspects of modularity, I don’t feel that in and of itself solves the greater goals of object relationship management, wherein we’d like to loosely-couple object references through inversion of control. Publishing modules to static URIs within a namespace tree forces them to look outside their factory scope to make references to other components, which cements application architecture and defeats encapsulation. The result begins to feel suspiciously like traditional speghetti code within a fancier wrapper. I’d argue that true modularity takes this a step further by completely encapsulating a component’s behavior from all out-of-scope references (window being of of them), in favor of loosely-coupled references made through dependency injection. Modular frameworks such as Require.js take this to the extreme by cometely eliminating the need for application namespace through its dependency manager.

By: Tom

Tom — Sat, 13 Oct 2012 08:41:14 +0000

Unless I’m missing something, this won’t allow you to create multiple instances of MyClass using new, which is what David’s second pattern achieves?

By: kyb

kyb — Fri, 12 Oct 2012 13:10:43 +0000

I prefer using this style, but it doesn’t play well with the jsdoc-toolkit.

By: tuzemec

tuzemec — Fri, 12 Oct 2012 12:40:20 +0000

Stoyan is at Facebook now.
And yep, the book is really good.

By: Andrew

Andrew — Fri, 12 Oct 2012 09:11:22 +0000

Also try qbaka.net to monitor JavaScript errors that users experience in production.