#module pattern

Anonymous Closures

This is the fundamental construct that makes it all possible, and really is the single best feature of JavaScript. We’ll simply create an anonymous function, and execute it immediately. All of the code that runs inside the function lives in a closure, which provides privacy and state throughout the lifetime of our application.

I am currently quite humbled by this article. I bumped into it as I was reading about require.js. I was reading about require.js in an effort to understand what is the best way to package together numerous underscore templates without throwing all of them into inline JavaScript tags, or requiring many JavaScript or HTML files. I began to read about the issue of making numerous requests for each of these files and with that began to understand the impetus for build tools such as Grunt, which in production would auto-compile these separate and numerous templates into one minified file, which could be served in one request, while retaining a happily modular experience in development.

Well but so having been programming far more in C# (and lightly in Ruby) recently, and not so much in JavaScript, I found earlier in the day that I was thinking "hmm, it's too bad there are no private methods in JS.."

And now here was the reminder of the true power of the module pattern, which I had sort of learned before--in that I do use it to keep from polluting the global namespace--but I had totally neglected to realize its full power. In using closures, we can absolutely privatize whatever we need to privatize. The beauty of the module pattern is that if we want a private method to be accessible only to that module, all we have to do is declare it using a function declaration, without retaining a reference to it. For a public method, on the other hand, we use a function expression for declaration, thereby retaining a reference to the function, on the object to be exported by the module.

Today's focus was some fuuuun Javascript games!

I understood the concept of a callback before, but now that I've had more practice, I'm a lot more comfortable with it. JavaScript doesn't wait for certain events (typically user input) to happen, it just executes code straight through. This can be a problem when your subsequent code relies on that result (user input) in order to execute properly. The solution is, Callbacks! A callback is a closure that is passed to a function, usually one relying on delayed timers or user input, and is saved for later use.

Aidan and I started the day by building a simple clock that ticks an updated time to the console using setInterval and a callback to update the output. It was much simpler than expected, like most project I've worked on recently, but still very cool. We then played around with accepting user input from the console with an simple add numbers and bubble sort programs. The add numbers accepted numbers to add together from the user and then performed the addition and printed it out to the console. The bubble sort relied on the user to tell the program is one element was bigger than the next and then continued sorting recursively, just like our normal recursive bubble sort, except the program knew to use the provided callback once the input was given into the console. Small steps :)

We used the readline js library a lot today to test out our callback knowledge, which caused some difficulties, seeing as how the library is only on v0.10.25 and is apparently pretty buggy. We ran into some issues where our logic was written correctly, but the readlines library still wouldn't wait for our use input and would skip directly to the next line. This made it difficult to test our logic and continue to the next portion of code, but ultimately we still got it all done correctly :) Go us.

We also wrote a small program, myBind, which was a good exercise in understanding the different scopes of the 'this' keyword, which is changed depending on which function calls it and how that function is called. In order for 'this' o be set as expected, the function must be called method style on an object, or set explicitly with bind (or in this case my own myBind function).

Lastly, towers of Hanoi and TicTacToe!

I'm well versed in Hanoi strategies at this point (after doing it in Java, ruby multiple times, and now javascript). One could call me a pro Hanoier.

The logic was pretty much the same as when we did these projects in ruby, but we had to be very careful of the differences between JS and ruby and the nuances of JS. We had some issues again with accepting user input because the readlines library seemed to be buggy and also caused all of our user input to the console to appear doubled like so " ccccooonnsssoolleee...looogg(((""doo tthhiiisss"")));; " which was quite confusing, but we worked around it. We also have to make sure our tictactoe players (Human and Computer with simple AI) inherited correctly from each other so that the game could play the same regardless of which type of player was currently playing.

We made sure to namespace our games correctly using the module pattern so that they can easily be included as libraries in other programs. It's a good habit to use in all of my new javascript programs.

Today we're going to discuss an effective set of patterns for large-scale JavaScript application architecture. The material is based on my talk of the same name, last presented at LondonJS and inspired by previous work by Nicholas Zakas.

Modules

Facade