I would like to turn this function:
const get1 = (v, d) => path(split(/[[\].]/, d), v);
get1("a.d", {a:{d:"f"}})
into a pipe or a compose function without the need of using it like so:
get1("a.d")({a:{d:"f"}})
I would like to turn this function:
const get1 = (v, d) => path(split(/[[\].]/, d), v);
get1("a.d", {a:{d:"f"}})
into a pipe or a compose function without the need of using it like so:
get1("a.d")({a:{d:"f"}})
I guess I'm curious as to why on two questions. First, is there something wrong with fn (a) (b)
? I'm personally finding that I now lean to that first even when I don't have to. Is is simply personal preference or is there something deeper there?
Second, why do you want to rewrite a perfectly readable function to use pipe
/compose
? I'm one of the founders of Ramda, and I love the library, but I certainly don't see a need to make everything point-free.
As to how, Hitmands already gave a reasonable answer, using Ramda's somewhat odd useWith
. An alternative is to pipe
/compose
and feed the results into uncurryN
:
const get2 = uncurryN (2, pipe (split (/[[\].]/), path))
console .log (get2 ("a.d", {a: {d: "f"}}))
<script src="//cdnjs.cloudflare.com/ajax/libs/ramda/0.27.1/ramda.js"></script>
<script> const {uncurryN, pipe, split, path} = R </script>
But either of these answers seems less readable than the original.
This should help:
const fn = R.useWith(R.path, [R.split('.'), R.identity]);
console.log(
fn("a.d")({ a: { d: 'f' } }), //curried call
);
console.log(
fn("a.d", { a: { d: 'f' } }), //call with two arguments
);
<script src="https://cdnjs.cloudflare.com/ajax/libs/ramda/0.27.1/ramda.js" integrity="sha512-3sdB9mAxNh2MIo6YkY05uY1qjkywAlDfCf5u1cSotv6k9CZUSyHVf4BJSpTYgla+YHLaHG8LUpqV7MHctlYzlw==" crossorigin="anonymous"></script>