undefined

points

[-]

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.

by flufluflufluffy11 hours ago|

prev|

[-]

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>)

by LittleLily10 hours ago|

parent|

[-]

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 })

by yojo14 hours ago|

prev|

[-]

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.

by BariumBlue14 hours ago|

prev|

[-]

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.

by chrisandchris14 hours ago|

prev|

[-]

> 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 );

by franey14 hours ago|

parent|

[-]

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.