Hacker News Reader

Comment by franey | Hacker News Reader

At least in TypeScript, it's a bit clunky to type, and I usually forget the order of the reduce function's arguments (accumulator, current item). Maybe it's just me, but it's especially easy to forget the order when the position of the accumulator is the 1st argument to the callback but the 2nd argument of the reduce function:

    array.reduce(
      (accumulator, currentItem) => {...},
      initialValue,
    )

In .filter(), The current item is the 1st argument and the intermediate/accumulated value comes later: filter((currentItem, index, intermediateArray)) => ...)

I use .filter() more often, so that argument ordering where currentItem is right next to the array is more intuitive for me

View on HN

The type annotation gymnastics you sometimes have to do when reducing to an object in TypeScript are annoying.

allTasks.reduce((acc, item) => { acc[item.label] = t => t.item.label === item.label; return acc; }, {} as Record<string, (t: typeof tasks[number]) => boolean>)

I agree it's a bit annoying, but a better solution than using `as` is just telling reduce what its generic type should be:

tasks.reduce<Record<string, (t: typeof tasks[number]) => boolean>>((acc, item) => ..., {})

Also imo it's cleaner to reduce to an object with something like this as the callback:

(acc, item) => ({ ...acc, [item.label]: t => t.label === item.label })

oh man I somehow never realized I could just use that square bracket syntax. must update everything

I think I've written this before and generally people are horrified, but a neat trick I like to do for a little bit of concurrency is making the first argument an async function.

That means you have to await the accumulator at some point before you return it, but anything you do before that call all gets fired off immediately. Then each invidivual iteration waits for the one before it to finish before finishing itself.

It's a pretty niche pattern, but it's a good way to make your coworkers do a double take while giving you quite a bit of control over exactly how it behaves. Similar to Promise.all, but more expressive I feel.

In TS/JS you’re usually inlining the reducer fn, and there’s something hard to read/especially ugly about the comma after the bracket or arrow fn into the initalValue.

That said, when I’m reducing a list, I still use reduce.

It literally may be a syntax thing, but I too can never remember the exact arguments to put where so I never use it.

I think if `reduce` looked more functional or more like Erlang code, it'd be easier to read and digest.

> accumulator

I had similar trouble, but I know call the "accumulator" just "previous" which makes it more logical in my head:

.reduce( (previous, current) => previous+current, 0 );

That's an interesting idea. I might get hung up for cases where "previous" is a different type from "current", like if you're reducing a list of objects into a single object. You've got the current item of the array and the current state of the accumulator, so they're kind of both current. Or you've got the last state and current item, but "last" is ambiguous.

In general, I find that if something is hard to describe in plain language, it's hard to code. Reducers are a bit clunky to talk about, which could make them harder to reason about, too.

Reply on news.ycombinator.com