JavaScript is interesting in that it enforces no particular structure upon you. “Bring Your Own Organization”, if you will. As I write more and more JavaScript in web app sites, this becomes more and more interesting. How you structure your JavaScript is very important because:<\/p>\n
Before I go any further, let it be known that I am far from a master of JavaScript. There are a lot of smart folks in the JavaScript world that have been doing and talking about this for longer than I knew what a div was.<\/p>\n
This has been a topic in my mind lately because I’ve been writing a lot more JavaScript for CodePen<\/a>, which is very JavaScript heavy. We’ve been using the “Module Pattern” since the beginning and it’s been serving us quite well I think. <\/p>\n Then I posted this article about the making of the Treehouse ad<\/a>, and within it I also used the Module Pattern for the JavaScript there. Louis Lazaris chimed in that this is how he’s been liking to write JavaScript lately too, and started a bit of a discussion<\/a>. Louis followed it up with an article<\/a> explaining his preferred structural pattern.<\/p>\n It’s easier to understand concepts like this if there is an example to build from. Let’s say we’re building a news widget. It lists some news articles, and has a button in which you can load more news articles.<\/p>\n Humble beginnings:<\/p>\n Just an object. I like my JavaScript variables starting with a lowercase character, but Modules get an uppercase first character. Just a convention that helps code readability.<\/p>\n The news widget will likely have some significant numbers associated with it (e.g. how many articles in it). Also, some significant elements (DOM nodes) that will need to be accessed regularly.<\/p>\n There will be a number of sub-functions of this module that do small specific things. Many of those may need access to these settings and “cached” elements. So, we’ll make the settings available to each of them.<\/p>\n We’ll get to the sub-function access in a second.<\/p>\n To “kick things off” we’ll have just one<\/strong> function be called. This will be consistent across all modules, so you know exactly where to look when you start reading the code and figuring out what happens when.<\/p>\n The first thing the Alex Vasquez set up a convention for us at CodePen where we would have a function just for binding the UI events. You never write any code that “does stuff” when you bind, you just do the binding and then call another appropriately named sub-function.<\/p>\n Chances are the news widget isn’t the only JavaScript you’ll have on a page. There will be lots of Modules you’ll need to load. Perhaps the news widget is on every page of your site, so belongs in a global.js file. This global.js file will ultimately be a a bunch of Modules concatenated, and then a big kick off party.<\/p>\n There are all kinds of ways to handle this concatenation stuff. It could be a dev tool like CodeKit and it’s ability to do appends\/prepends<\/a>. It could be some fancy Grunt.js<\/a> build script thing. <\/p>\n At CodePen we use Ruby on Rails and it’s asset pipeline<\/a>. So for us, the global.js file would be something like:<\/p>\n Pretty darn satisfying way to write JavaScript, I think. It satisfies the three points I made about the importance of structure. <\/p>\n Regarding the testing point, I know that wasn’t discussed much, but I’m sure you can imagine how having smaller specific functions in change of specific tasks are easier to write assertions for. That’s how most JavaScript testing is done (e.g. Jasmine<\/a>). For instance, in some form of code or another: “I assert that when this function gets this value this other thing happens and is equal to some other value.”<\/p>\nThe Concept<\/h3>\n
The Module<\/h3>\n
var NewsWidget = {\r\n\r\n};<\/code><\/pre>\nSettings<\/h3>\n
var s,\r\nNewsWidget = {\r\n\r\n settings: {\r\n numArticles: 5,\r\n articleList: $(\"#article-list\")\r\n }\r\n\r\n};<\/code><\/pre>\nInit Function<\/h3>\n
var s,\r\nNewsWidget = {\r\n\r\n settings: {\r\n numArticles: 5,\r\n articleList: $(\"#article-list\"),\r\n moreButton: $(\"#more-button\")\r\n },\r\n\r\n init: function() {\r\n \/\/ kick things off\r\n s = this.settings;\r\n }\r\n\r\n};<\/code><\/pre>\ninit<\/code> function will do is set the variable s<\/code> (which we declared at the same level as the Module) to be a pointer to the settings. Because of where s<\/code> was declared, this means all sub-functions of the Module will have access to the settings. Nice.<\/p>\nBinding UI Actions<\/h3>\n
var s,\r\nNewsWidget = {\r\n\r\n settings: {\r\n numArticles: 5,\r\n articleList: $(\"#article-list\"),\r\n moreButton: $(\"#more-button\")\r\n },\r\n\r\n init: function() {\r\n s = this.settings;\r\n this.bindUIActions();\r\n },\r\n\r\n bindUIActions: function() {\r\n s.moreButton.on(\"click\", function() {\r\n NewsWidget.getMoreArticles(s.numArticles);\r\n });\r\n },\r\n\r\n getMoreArticles: function(numToGet) {\r\n \/\/ $.ajax or something\r\n \/\/ using numToGet as param\r\n }\r\n\r\n};<\/code><\/pre>\nCombining Files<\/h3>\n
\/\/= require common\/library.js\r\n\r\n\/\/= require module\/news-widget.js\r\n\/\/= require module\/some-other-widget.js\r\n\r\n(function() {\r\n\r\n NewsWidget.init();\r\n\r\n SomeOtherModule.init();\r\n\r\n})();<\/code><\/pre>\nThat’s All Folks<\/h3>\n