Ability to choose which input param to pass to a func

[dalefrancis88]

Is your feature request related to a problem? Please describe.
Yes, their are some frameworks where the event handlers pass the instance of the component as the first param.

Describe the solution you'd like
I'd like to see a function i could use to choose which param to take and pass to a containing func

Describe alternatives for how you do this now
I write in place funcs (_, a) => f(a)

Code

import { curry } from 'crocks'

const param = curry((index, f) => (...args) => f(args[index]))
const param1 = (index, f) => (...args) => f(args[index])

param(2, x => x + 2)(2, 3)
param1(2, x => x + 2)(2, 3, 4, 5, 6)

[dalefrancis88]

This is how Ramda implemented it

https://ramdajs.com/docs/#nthArg

[RichardForrester]

I keep seeing this issue thinking that you’re talking about a placeholder. Can’t you just use nthArg from Ramda?

[dalefrancis88]

Quite possibly but while for some it's common to use Ramda many people don't use it in conjunction with crocks. It's a bad habit to just grab all the libraries for the sake of a few functions and so if it would be valuable within the library it gets put forward as a discussion point.

Other than "it's already in Ramda" do you see a major issue with it?

[evilsoft]

TBH, It is my opinion that writing the in place function could read a bit better, because you can provide the name of the argument you are trying to capture and can see the "shape" of the function. That is the reason I am opposed to adding placeholders to crocks. Puts an undue cognitive burden, in my opinion, on anyone else (including future me) that has to parse and maintain it.

This could also open a can of "well what if I want the second and third".

I can say the same thing with this. BUT unlike placeholders, I am not totes opposed personally, if this gets support I do not see why this would be bad thing (other than possible additional cognitive load). Although we may wanna come up with a better name (says the person with no good examples of what that should be).

[RichardForrester]

No issue with nthArg specifically. I suppose it's a difficult philosophical problem for library authors to decide just exactly where to draw these lines regarding compatibility/duplication with/of other libraries.

I will say that if Crocks is meant to completely supplant a utility library like Ramda, then it has a lot of missing functionality. It may serve to make a list of all the functions Ramda provides, separating the functions that should return an ADT, e.g., head, from those that merely operate on and return native arrays and objects or a provided data structure.

Speaking personally, I came looking into Crocks, Folktale, Sanctuary and others because Ramda does not provide Maybe and Either - simple as that. All of the functions that should return a Maybe can return undefined which is just not acceptable. The vast majority of Ramda's functions however don't suffer from that problem and I see no reason to duplicate them. I think it's okay to assume people will be tree-shaking.

[dalefrancis88]

closing for now till we find enough requests to validate adding it to the library