Archive

Archive for July, 2011

Easy functional programming in JavaScript with Underscore.js — part 2

July 29th, 2011 4 comments

In the previous post I showed how good use of Underscore.js‘s map function can substantially increase the quality of your code. This time I’ll explore some other functional collection favourites: reduce, select and all.

Reduce that array over a low heat until thick and creamy

Have you ever had to do something like this?

Basically, this is going through some kind of list of values, calculating a new value from each one and accumulating some kind of answer. It’s a common pattern, and there’s an Underscore function for it! This is exactly what _.reduce was built for:

_.reduce takes a collection of values, a function, and a starting value. In this case, the starting value is 0 because we’re building up a running total of numbers. The function is passed the running total (which starts at 0) and each element of the collection. The return value of the function becomes the next value for the running total. _.reduce doesn’t just need to be used on numbers:

In this case, I’m reducing an array of animal objects into a single string. Of course there are plenty of ways to do the above, but this shows you the flexibility of _.reduce.

Bo Selecta!

Imagine you have an array of strings, but you want a new array of strings that start with a capital letter. You might do that like this:

Now, you won’t be surprised to learn that there’s an Underscore function for doing just that: introducing _.select!

Isn’t that much cleaner? Again, we’re abstracting away the minutiae of selecting elements from a list, and just declaring that we want the elements that start with a capital letter. Simples!

All the single ladies

Sometimes you just want to know a yes or no answer about a collection. For example, are all my ladies single?

Hell yes they are. You can read _.all as “is this statement true about all the elements in my collection?” In the same way, _.any can be read as “is this statement true about any of the elements in my collection?”

What about this?

Here’s a useful little tip. When you’re working with nested functions in an object context, you’ll find that this in the nested function doesn’t refer to the object’s context, but the global context. The standard way to deal with this is a line like that = this; or self = this;. There’s a nicer way to do this with Underscore. Nearly all the functions for working on collections take an optional context argument, which specifies what this will be inside the function. Here’s an example:

Because we’re passing the value of this to _.select, the function passed to _.select is working with the correct this. Otherwise, this.maxAge would be undefined.

Learning more

I’ve only gone into some of the functionality that Underscore offers. The docs are very approachable and clear – I urge you to go and read them.

@SamirTalwar on Twitter recommended that I show the alternative syntax for Underscore, as described in the docs. Basically, instead of doing:

_.map(collection, func);

you can do:

_(collection).map(func);

And, coupled with .chain() you can do awesome chaining things like this:

Pretty cool. Anyway, use whichever feels right to you. Enjoy!

Categories: Programming Tags: ,

Easy functional programming in JavaScript with Underscore.js — part 1

July 27th, 2011 6 comments

So, you’ve been developing in JavaScript for a while, you’re getting on quite well with your for and while loops, when somebody comes along and tells you you shouldn’t be doing that, that JavaScript is a functional programming language and there’s much better ways to solve most problems that with loops. Whaaa…? Well, that’s what I’m here to tell you anyway.

What is functional programming?

Functional programming (FP) is all about the idea of functions as a mapping from one value to another. An FP function just turns one value into another – it doesn’t have side effects. Side effects are anything that happens within the function that changes something outside of the function. For example, changing the value of a variable not defined in the function, or logging output, or showing an alert message … basically anything that happens in the function. The only thing an FP function does is takes in a value, and returns a new value.

Another interesting thing about FP is the use of higher-order functions. These are functions that either take or return functions as values (or both). I’m mainly going to be looking at functions that take other functions as parameters, because there are some interesting things you can do with that.

An underscore, courtesy of Wikipedia

Functional programming in JavaScript is made a lot easier with a suite of functions called Underscore.js all packed into a minified script of just 3kb. Underscore provides a selection of common FP functions for working on collections, like map, each, reduce, select etc. I’ll walk through some of these to demonstrate the power of FP. Note that functional programming isn’t just about working with collections – there are lots of other exciting things you can do – but for now I’ll concentrate on the collections.

Mapping over an array

One of the most widely used Underscore functions is _.map. This takes an array and a transforming function, and creates a new array based on the return value of the transforming function. That’s a bit abstract so I’ll give you an example:

So, _.map is passed an array, and a function. That function is called on each element of the array in turn, and the return value of the function gives the corresponding element in the new array. Note that the original array is left intact. The _.map function takes an array, and returns another array – it’s a mapping from one value to another.

You can do much more interesting things with _.map than just multiplying numbers though. You could transform an array of strings into an array of cats!

I hope you’ll forgive me for using two Underscore functions there. First off, we’ve got _.map. In this case, we’re going through the array of cat names, and creating an array of cats. The second is _.each. This, like _.map, goes through each element of the array, passing them into the function, but it doesn’t care about the return value. It just executes the function and carries on with its life. Now, if you’re concentrating, you may have noticed that each isn’t actually a mapping from one value to another, and you’d be right. _.each is only useful if you allow side effects, for example console.loging. A JavaScript program isn’t much fun without any side effects, because you’d have no idea if anything happened otherwise. The key to functional programming is minimising the side effects.

What’s great about _.map is that once you’ve learned to read it, and understand what it does, it really succinctly explains the meaning of your code. In that cat example, you can see that all the _.map function is doing is turning strings into cats. That’s all you need to know. The old-school JavaScript technique would look like this:

In comparison, isn’t that just damn ugly? I mean, to read that you need to keep track of the array, and the array index, and the length of the array, and you have to make a new blank array to contain the new cats, and … you get the point. It’s mixing up the how with the what. All I care about is that I’m getting an array of cats, from an array of cat names. Don’t bother me with insignificant details like array indices.

Here’s another example: constructing a query string:

This one uses an object, but the same principles apply. From a list of key/value pairs, we’re constructing an array of ‘key=value’ strings. Then all you need to do is join the array with &s. This describes how a query string is formed much more declaratively than the standard

append the key, then an equals, then the value, then an ampersand, then the next key, then the next value, then another ampersand, then – oooh we’re at the end – better get rid of that last ampersand, whoops!

Go forth and map-ify!

I hope that’s given you some ideas as to how functional programming can be used in JavaScript. And I really hope that you can begin to see how much cleaner your code can get when you cast out the for loops and embrace the _.map. If all you’re after is map and each, and you’re using jQuery, you’ll be glad to know both functions have jQuery equivalents: jQuery.map and jQuery.each, albeit with a slightly different API. Next time I’ll be looking at some of Underscore’s other functions, for the times when _.map just won’t cut it.


Part 2 is now up!

Categories: Programming Tags: ,

Test-drive your JavaScript!

July 23rd, 2011 5 comments

Testcard

JavaScript is such an important language today. It’s stopped being a toy scripting language, and become a serious programming language. Unfortunately, the vast majority of JavaScript developers don’t unit test their code.

Testing is a vital part of modern development. Code without tests isn’t code – it’s random scribblings that may or may not be executable. Even if they are executable, the only way you can tell if they all work is by loading your application or website, and trying out every single thing that a user could possibly do.

Test-driven development (TDD) is a really nice way of developing software by writing tests before you write the code. If you’re not used to this way of working then it sounds like a weird way to do things, but hear me out.

Imagine you’re building a web app. You wouldn’t just write the whole thing, then open up a browser and see if it works. You’d write a small bit, open the browser and see if it does the expected thing. If it didn’t, then you’d work out why, then fix it, and look again. Then you’d do the next bit.

TDD is just like that, but easier. With TDD, instead of going to the browser each time and seeing if what you’ve just written works, you write a bit of test code that checks that your code does the expected thing. Once it does, you write another test that checks the next thing you’d like it to do. The advantage of working this way is that every time you run your tests, you’re running all of the previous tests you’ve written. That way you can see if something you’ve written to get the most recent thing working ended up breaking something you did earlier. If you were going to do this the old way, you’d either have to check everything every time you made a change, or risk breaking other things that you’re not concentrating on right now. A good test suite will run in under a second, so you get instant feedback whenever you make a change.

Using TDD also means that you end up thinking about the application in a much more sensible way. It forces you to limit the interactions between different bits of the code, which makes the code much easier to modify at a later date.

A side-effect of TDD is that you end up with a comprehensive test suite that can be used to verify the behaviour of your app.

Ok – I’m sold!

Now, TDD takes some practice. You need to learn the tools and the techniques so you can get to the point where you actually write code faster when you’re test-driving it. So, how do you get there?

Test-Driven JavaScript Development

The best book I know on the subject is Test-Driven JavaScript Development by Christian Johansen. This book works on the assumption that you’ve never done TDD before, and gives an excellent grounding in both TDD in general, and how to do it in JavaScript. This is done through example code that you can write and test as you read the book. By the time you finish the book you’ll know how to do TDD, you’ll have some awesome tools for testing JavaScript, and you’ll have written a Node.js app!

If you’re not sure whether you want to get the book yet, have a look at the author’s introductory testing article on Script Junkie.

Testing tools

Although the author of Test-Driven JavaScript Development advocates the use of Google’s JSTestDriver, I much prefer to use Jasmine. If you work with Ruby you’ve likely used RSpec – Jasmine is basically RSpec for JavaScript, but with some ideas of its own as well. Jasmine is a BDD framework, not TDD. BDD (behaviour-driven development) is like TDD, but with a different emphasis and slightly different philosophy (and terminology). To find out more about BDD have a look at the Wikipedia page, as it’s outside the scope of this article.

Finally

I hope I’ve convinced you by this point that testing is worth it – even in JavaScript. I also hope that you’ll give TDD a go, as I think it’s (a) a great way to develop software, and (b) a brilliant way to create a test suite for your code. It does take a bit of time to set everything up the first time, and to learn the right techniques, but that time will pay for itself over and over again, when you have applications that actually do what they’re supposed to do, and don’t break when you change them. So please, do give it a go, and let me know how you get on!

Categories: Programming Tags: ,