Question

If I have an array of objects in a var. I want to reduce this so that they are grouped by particular property. This is my code

array = tracks.reduce (x,y,i) ->
    x[y.album] = []
    x
, {}

albums = tracks.reduce (x,y,i) ->
    array[y.album].push {'name':y.name, 'mp3':y.mp3}
    array
, {}


console.log(albums)

It outputs what I want, however I want to know if there a better way to write this, without having to do the first loop, to create the empty arrays for the groups.

Thanks.

Answer 1

Yes, you can use the or= or ?= operator to assign array[y.ambum] only if it hasn’t been initialized; therefore using only one loop. BTW, i think it’s a bit confusing that the array variable is an object. Another way of coding this using a CoffeeScript loop instead of reduce is:

albums = {}
for {album, name, mp3} in tracks
  (albums[album] or= []).push {name, mp3}

Notice that i’m using destructuring to get the track properties all at once.

Or, if you want to use a reduce:

albums = tracks.reduce (albums, {album, name, mp3}) ->
  (albums[album] or= []).push {name, mp3}
  albums
, {}

But i think the CS-loop version reads a bit better 🙂

Bonus track (pun intended): if you happen to have Underscore.js, i’d strongly recommend to use groupBy, which does exactly this kind of grouping job:

albums = _.groupBy tracks, (track) -> track.album

Notice that the tracks for each album name in albums will be “complete” tracks (not just the name and mp3 properties).

---

Update: A comment about performance: when asked to do something “efficiently” i interpret it as doing in the most direct and clean way possible (i’m thinking about the programmers’ efficiency when reading the code); but many will unequivocally relate efficiency to performance.

About performance, all these three solutions are O(n), n being the number of tracks, in complexity; so neither is horribly worse than others.

It seems raw for loops run faster on modern JS engines than their equivalent higher order brothers: forEach, reduce, etc (which is quite saddening IMO :(…). So the first version should run faster than the second one.

In the case of the Underscore version, i won’t do any prediction, as Underscore is known for using the higher order functions a lot instead of raw for loops, but at the same time, that version does not create a new object for each track.

In any case, you should always profile your code before changing your solution to one that might be more performant but is less readable. If you notice that that particular loop is a bottleneck, and you have a good set of data to benchmark it, jsPerf can be really useful 🙂