G'day:
Here's the next effort in going over how these higher-order functions work compared to writing procedural code in CFML tags. The previous one was "CFML higher-order functions compared to tag-based code: map function". Today I'm looking at the reduce method. As per yesterday, I've discussed this before in ColdFusion 11: .map() and .reduce().
So what does reduce to? It helps if we compare it to map. Remember how I said this yesterday:
A mapping operation takes one collection and remaps the values for each key into a different value. The keys and the overall size and order (if it has a sense of order) of the collection is preserved. Also the original collection is not altered; an entirely new collection is returned.
A reduce operation is used to return a different data structure. It doesn't mean "reduce" in the sense of "make smaller"; the resultant data structure might be "bigger" (for some definition of bigger). Or it might be the same length, but a different type.
An example of returning the same length but different type would be similar to yesterday's example of mapping an array of records to an array of objects:
records = [
{id=1, mi="whero", en="red"},
{id=2, mi="kakariki", en="green"},
{id=3, mi="kikorangi", en="blue"}
]
objects = records.map((record) => new Colour(record.id, record.mi, record.en))
A more likely scenario in CFML is for the records to be a query. But one still wants to pass an array of objects back from the storage tier to the application, so we use reduce to make the type conversion:
records = queryNew(
"id,mi,en",
"integer,varchar,varchar",
[
[1, "whero", "red"],
[2, "kakariki", "green"],
[3, "kikorangi", "blue"]
]
)
objects = records.reduce((objects=[], record) => objects.append(new Colour(record.id, record.mi, record.en)))
Note the way reduce works. The first argument is an "accumulator" that is passed into every iteration, and is ultimately returned to the calling code. One builds the return value iteration at a time into that. Here I'm appending to the array of objects each iteration. Whatever is returned from each iteration is the first argument of the next iteration. So as I iterate over the query, I start with an empty array. I append the first object to it, and that one-element array is then passed into the accumulator of the second call to the callback in the next iteration; and so on for all iterations so ultimately I have an array that I've appended three objects to. Some pseudo-code might make this more clear. Let's consider the iterations as they progress:
1: objects argument=[]; append Red; return value=[Red]
2: objects argument=[Red]; append Green; return value=[Red, Green]
3: objects argument=[Red, Green]; append Blue; return value=[Red, Green, Blue]
result: [Red, Green, Blue]
We start empty, we append red, we append green, we append blue.
After that first argument, the subsequent arguments follow the same pattern as with map: the second argument is a row of the query (passed as a struct). The callback can also receive the current index / key (or currentRow equivalent to a query loop in this case), and the last argument is the entire query. I don't need these here, so do not mention them in the callback's function signature.
The tag version of this is actually round about the same amount of code (109 bytes vs 112 bytes it seems):
<cfset objects = []>
<cfloop query="records">
<cfset arrayAppend(objects, new Colour(id, mi, en))>
</cfloop>
Another case is shown here:
transactions = [
{id=1, amount=.1},
{id=2, amount=2.2},
{id=3, amount=33.3},
{id=4, amount=44.44}
]
sum = transactions.reduce((sum=0, transaction) => sum += transaction.amount)
We're summing the transactions. We are reducing the collection to a single value, I guess.
Oh one thing maybe work making very clear: it's complete coincidence that the final variable is called sum, and the accumulator parameter is called sum. They don't need to be, it just makes sense to me to match them up given we're kinda building the end result in that accumulator argument, and accordingly it's going to be the same sort of values, so makes sense it's called the same thing.
The tag-based version for this is simple again:
<cfset sum = 0>
<cfloop array="#transactions#" item="transaction">
<cfset sum = sum += transaction.amount>
</cfloop>
Another more complicated example of script-vs-tags when reducing is in yesterday's article "CFML: tag-based versions of some script-based code". There I am reducing a query to a struct, then reducing that struct into another query. Both CFScript and tag versions of the code are in that.
One thing to not use reduce for is to actually reduce the size of a collection by removing records from it, eg:
numbers = [1,2,3,4,5,6,7,8,9,10]
evens = numbers.reduce((evens=[], number) => number MOD 2 ? evens : evens.append(number))
One would not use reduce for that. One would use filter. I guess I'll get to that tomorrow.
Righto.
--
Adam
