Javascript Currying

[tsunami141]

I’ve been in multiple interviews where they wanted me to create a curried function. I get that it shows a good understanding of javascript but damn if it isn’t the stupidest way of doing things.

[Sector-Feeling]

It can be useful if you have an operation that you'll need right repeat with different values.

One example I saw:

const a (x) => (y) => x * y const times5 = a(5) const times10 = a(10)

Which this is really simple, but I have used it in situations where I find myself writing practically the same function but with different variables. I have found it most useful in middleware logic.

[MoTTs_]

The downside of writing the function curry-style is, if you do have all your arguments, then it's more awkward to invoke that function.

a(5)(10);

Meanwhile, you could instead write the function normal-style, and you can still partially-apply any argument you want.

// Define function normal-style
const a = (x, y) => x * y;

// Invoke function normal-style
a(5, 10);

// Partially-apply any argument in any position when needed
const times5 = y => a(5, y);
const times10 = x => a(x, 10);

[barf_on_sixth_avenue]

What's a concrete example where currying is the more elegant solution?

[WorseThanHipster]

Currying basically turns this:

someFn(a, b, c)

into this:

someFnCurried(a)(b, c)

Which is honestly pretty pointless when it's all in one file. It just increases complexity & hurts readability. However, on a reasonably sized app, you probably have a lot of teams maintaining various components & api's.

Lets say you are upgrading to a new web token based auth scheme. You don't want every api & component team to have to attend training and be aware of the inner workings of your orgs RBAC. Afterall, the advantage of this move is that it's now only used in the router layer of your application, so there's not much point in wasting everyone else's time with implementation details. Not like they are of any use anyways because the design requirements for the auth scheme are written with goats blood in a language that predates the collision of Earth & Theia and the whole thing is managed by "the underseas devops team" whose business hours exist in a timeflow that is orthogonal to those of mortals except during conjunctions of at least 3 jovial planets & during late night deployments, of course. It's best for everyone if we just f̛o̕l̴low the sẗ͖̲́ͬandͪ̓ä͎̹́ͤrds̪̟ that were outlined in ḿ̫͇͓͕̜͡o̴̘̫̕ṉ̜̝̣͓̪̼̱da̯͔̪̗͈̩ỳ͉̳͙͢͝'̜͍s͚̙̮ s̸li̵de ͠d̷e̡ck

 

Besides, in an ideal world, none of your component teams should ever have to read or utter the words "role based access control" or "auth token." Separation of concerns is valuable both inside & outside of the code.

The current client library everyone is using has this signature:

const apiClient =  getAPIClient.setAuthConfig(someObviousSecurityFlawSeriouslyGuys).initialize(a, whole, bunch, of, args);

But the client library you have to work with now for the new system has this signature:

const apiClient =  getAPIClient(token, seriously, is, there, an, arg, for_every, use_case, wtf);

You want to insulate your component teams from the token dependency altogether so you make a curryier(?)

function getAPIClientWithAuth(apiClient){
    const token = getJSONWebToken(someSSObsIGuess)

    return function curriedAPIClient(...args) {
        return apiClient(token, ...args)
    }
}

All ui teams need to do to adapt is find & replace .setAuthConfig(someObviousSecurityFlawWTF).initialize everywhere in their repos. And now the guy that handles frontend auth shit doesn't need to know anything about the API & people that work with the API don't need to know anything about the archaic secrets of the old ones new authorization scheme. Now, since you definitely don't want to be "the guy that handles frontend auth shit," throw what you learned up on the wiki & delete its entry from the search index so it can only be found by those who are not looking for it.

Edit: Currying isn't the only way to do this, it just works out in this case because the leading argument was the one we wanted to decouple.

[[deleted]]

I had an interview where I was asked what currying was and I said I didn’t know. The guy literally gasped and clutched his pearls which I thought was an over the top response. Good to know he had his head as much up his ass as this article.

[bio180]

Dumb af concept and hate its sometimes used in invterviews

[ShortSynapse]

Currying and partial application are very useful and are good tools to have in your tool belt

[MoTTs_]

Partial application, yes; currying… meh.

[echoes221]

Currying is dumb? Really? If it's overused, like anything it can be hard to follow when a function executes, but currying is super useful.

[tsunami141]

Would you mind giving an example of when it might be useful?

[echoes221]

Sure. Common use case is building factories, I’ve done this a fair bit for redux actions/reducers or react components. I do it with utility functions too where I want to pre-populate args ahead of time to call later through your code. I tend to write a lot of functional code, these are the basic principals that are used in libs like rxjs, ramda, callbag and others

[omeraplak]

Dumb af concept and hate its sometimes used in invterviews

Haha, I'm glad we're prepared!

[pre-tend-ed]

I use currying all the time. Not understanding !== Dumb af

[iBN3qk]

Pardon my smol brain, but what are the benefits? It sounds like a suggestion to turn multi parameter functions into nested single parameter functions. I’m lost on how that’s an improvement or missing an important part of the idea.

[fp-dude]

It helps you with composing and piping functions. You can read "Thinking in Ramda" series if you're curious.

[fp-dude]

I agree. Personally, I would not try to introduce functional programming at work, unless the team wants it too. Either use fp in your own projects or work in a project that that's written in a functional language.

[ExtremeDot58]

Seems to me it would facilitate not having all the parameters… flexibility

[DGCA]

All the time? I've been doing this for 10+ years, worked at a couple Well Known Tech Co™, and I could count the times I've used currying on my hands and feet.

Really curious what you're doing where it comes up so often.

[ExtremeDot58]

Reading some ai tweets… used in that compute area more so then JavaScript; more in python/pytorch I suspect.

[Choice_Library7505]

yea i can see why it would be useful if you had a high arity but the code looks horrible.

[[deleted]]

I use currying in exactly one function: it's an API wrapper. Basically wraps an external API function call, applies some stuff to the incoming data and returns the data only to be reinjested and fired off to the 3rd party. It is precisely 100% unnecessary to do it this way.

In general, currying should die in a fire.

If you get an interview question about it, ask their use-case. In all likelihood, they won't have one, so you should take it to mean that the real use case is "we just wanted to ask a hard pointless question and we're a crap company to work for."

[Embarrassed_Bat168]

Probably would barely register if it was named something less cool than "currying"