I started studying (advanced) JavaScript not only because I want, but also because my job is demanding JS knowledge right now. I found it to be really interesting, but I always feel like my code could be a lot better and more well organized.

Searching about JS, I found this Essential JavaScript Design Patterns book, which seems to be really useful.

 

So, have you read it? What do you think about it? Share your thoughts.

 

Bonus: do you recommend any obligatory JavaScript ebook/book?

 

PS: I didn't post the link because I don't have 25 posts, sorry.

I started studying (advanced) JavaScript not only because I want, but also because my job is demanding JS knowledge right now. I found it to be really interesting, but I always feel like my code could be a lot better and more well organized.

Searching about JS, I found this Essential JavaScript Design Patterns book, which seems to be really useful.

 

So, have you read it? What do you think about it? Share your thoughts.

 

Bonus: do you recommend any obligatory JavaScript ebook/book?

 

PS: I didn't post the link because I don't have 25 posts, sorry.

A few interesting patterns there, but I find mostly that I use DRY tactics and the Module pattern (I love the module pattern - check out how useful it can be).

The facade pattern is probably one of the most useful things you can use in JavaScript when you write things from scratch. It's most useful when trying to use modern methods while making allowances for older browsers. For example, a function that tells you where an instance exists in an array:

function inArray(needle, haystack) {
   // Modern browsers have an Array.indexOf method that returns the index of
   // the first occurence of the needle, or -1 if it's not found. Since all
   // native methods are faster and more effecient than anything we can write,
   // check to see if Array.indexOf can be used before simulating the
   // functionality. As a student of Douglas Crockfrod, I always declare my
   // variables at the top of any function, so I'll define them here even if
   // they'll never be used.
   var i = 0,
       il = haystack.length,
       retValue = -1;

   // The moment of truth; do we have access to this useful method?
   if (haystack.indexOf) {
       retValue = haystack.indexOf(needle);

   // Nope. Time to fake it.
   } else {
       for (; i < il; i += 1) {
           if (haystack[i] === needle) {
               retValue = i;
               break;
           }
       }
   }

   // Now return whatever we found. If we found nothing, we return -1.
   return retValue;
}

Finding the index of an item in an array is now a simple call like this, and it's guaranteed to work in any browser that can handle JavaScript.

var myIndex = inArray('three', ['one', 'two', 'three']);

It's also very useful for writing quick functions that you know you'll have to improve during the browser-testing phase. For example, here's a DOMReady function:

function domReady(func) {
   // All we need right now is to add an event listener to the
   // DOMContentLoaded event. Not everything knows what that is, but my
   // current browser does. I'll fix this during browser testing.
   return document.addEventListener('DOMContentLoaded', func, false);
}

So long as you only ever call your own domReady function, you can update this function instead of trawling through your code to see what needs activating.

 

Most of the time I find that my scripts tend not to be complicated enough to justify attempting them in a couple of patterns to see which one works the best. I usually find something that I like and stick with it. The revealing module pattern is yet to let me down.

Edited March 21, 201115 yr by Skateside