Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Sunday, March 2, 2014

Review: The Principles of Object-Oriented JavaScript - Nicholas C. Zakas

I generally compare all technical publications against Clean Code by Robert Martin and JavaScript: The Good Parts by Douglas Crockford. Both books are easy to read and provide good working examples.  If a book is the size of Code Complete, I probably won't read it. 


The Principals of Object-Oriented JavaScript is definitely concise and I recommend it to anyone learning JavaScript or working in a shop where the fundamentals of the language need to be taught.  This book promises to help those who come from a strongly-typed background and it delivers by providing specific examples on the commonalities and differences between languages like Java/C# and JavaScript.  I also enjoyed learning some new details concerning ECMAScript 5 - albeit several years late.


Music to my eyes

Make no mistake: A lot of the concepts you may have learned in more traditional object-oriented programming languages don't necessarily apply to JavaScript. 

Knowing the function's arity is important in JavaScript because functions won't throw an error if you pass in too many or too few parameters. 

JavaScript functions don't actually have signatures. A lack of function signatures also means a lack of function overloading.

ECMAScript 5 Learning

  1. Object.seal()
  2. Object.freeze()

Although I learned this from ng-conf 2014, Zakas adds this fantastic feature of JS that I didn't know - what an idiot I've been

  • get/set, really useful for coming up with your own $dirty checks, validation, etc.

THANK YOU FOR CONFIRMING THIS PATTERN!!!

  • Scope-Safe Constructors

Wished you would have covered more of this: Hoisting

Although Zakas covers hoisting as it pertains to functions, I really wished he would have covered this topic for variable declarations.  I especially HATE seeing documentation/standards within companies covering the declaration of variables within block scopes and JavaScript.  You can always tell those standards were written by Java/C# folks not understanding the JavaScript language.  Even Crockford doesn't go into too much detail about hoisting and it's frustrating just telling folks: declare at the top - trust me.

-------------------------------------------

It's safe to say I'll be recommending this book to my shop in the hopes it not only will improve our understanding of JavaScript but that it might lead to more folks becoming passionate about the language that I love.  

Saturday, February 8, 2014

Mocking Promise Objects within AngularJS

Assumption: You understand the value of breaking up your application into modules.  Too many: one module per service/controller, Too few: one module for entire application, assuming your application is not a basic TODO. Long story short: with modules, you can reduce the scope of your test without having to include the full application with each test.

Background: We’ve been using AngularJS to help with our new order entry system and it’s working great.  Testability is at the forefront of angular’s offering and we attempt to have as much valuable code coverage as we can within our application.  Early on, we encountered an obstacle while trying to test $q within a controller’s init function.

Obstacle:  One of our controllers has to init with a promise object and several of the scope objects within the controller depend on the resolution of the promise.

Controller to test


  • you can see we have a client module
  • product module is an external dependency, we don’t want to bring that module into our test
  • the product service returns a promise object, most likely $q since we’re using AngularJS

Test with mocked promise object



  • when we first encountered this problem, we were forgetting we were JavaScript developers…it’s easy to get caught up in the JS library itself and expect the library to solve all of your problems for you…can we use $httpBackend here? no…what if your promise isn’t really even working with http?  what if it is but you don’t want to test the http call since that (module) is out of scope for this test?…why doesn’t ng do something for us - who cares…JS is easy enough without ng!
  • since JS is one of the easiest languages to mock (if not the easiest), just create an object in your beforeEach to resemble the promise you require
  • you can see we mock the entire productService & testing the productService itself should be out of scope here
  • our test is really simple but it proves the concept for mocking promises