Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jan 31 2019 22:17
    CrossEye commented #2779
  • Jan 31 2019 21:04
    ArturAralin commented #2779
  • Jan 31 2019 20:08
    CrossEye commented #2779
  • Jan 31 2019 18:56
    buzzdecafe commented #2631
  • Jan 31 2019 18:09
    ArturAralin commented #2779
  • Jan 31 2019 16:18
    CrossEye commented #2779
  • Jan 31 2019 16:10
    CrossEye commented #2631
  • Jan 31 2019 16:06
    CrossEye commented #2777
  • Jan 31 2019 14:44
    ArturAralin opened #2779
  • Jan 31 2019 07:39
    inferusvv commented #2631
  • Jan 31 2019 03:07
    sespinozj commented #2771
  • Jan 31 2019 02:33
    machad0 commented #2771
  • Jan 31 2019 02:26
    JeffreyChan commented #2777
  • Jan 30 2019 14:30
    CrossEye closed #2777
  • Jan 30 2019 12:13
    vanyadymousky updated the wiki
  • Jan 30 2019 01:42
    JeffreyChan commented #2777
  • Jan 29 2019 21:06
    vanyadymousky updated the wiki
  • Jan 29 2019 16:28
    CrossEye commented #2777
  • Jan 29 2019 15:50
    mbostock commented #2772
  • Jan 29 2019 15:48
    CrossEye commented #2772
Patrick Laplante
Hello all, really dumb question. How would you handle something like a socket in a composition chain. For instance, how would I do something like this but using functional composition.
Url = “localhost:8080”
connection = open_connection(url)
result = Send_data(connection, data)
raw_response = Get_response(connection)
response = parse(response)
While I am not sure but it seems that get response should be receiving the result, if not you can curry it in but it could look like the following
        const sendData = R.curry(send_data)(R.__,data)
        const result = R.pipe(
            , sendData
            , get_response
sorry I missed some of the cases, get_response refers to Get_response and send_data refers to Send_data
if you wish to actually use compose, change pipe to compose and reverse the argument function order
Charles Hughes
I'm curious how people here generally approach debugging their Ramda code? I've found the easiest/most fluid way to be putting a breakpoint at the top of a pipe call and playing around with the code in the debug console in vscode. I've wondered if I should try Emacs since it seems to support more repl based development that I'm trying to replicate here...
I've been wondering how feasible it might be to write a little VSCode extension that would put the outputs of each line inline in faded text when you're on a breakpoint. It seems to me like it would be pretty difficult
Kurt Milam

@chughes87 I sometimes use something like this:

const log = x => (console.log(x), x)

const pipeLog = (...fns) =>
  pipe(log, ...intersperse(log, fns), log)

pipeLog(inc, inc, inc)(0) // logs 0, 1, 2, 3

// also

pipe(dec, dec, log, dec)(100) // logs 98

REPL: https://bit.ly/2QKz2P1

Matt McKellar-Spence
tap(console.log) is pretty easy for quick debugging.
var b = pipe(add(1), tap(console.log), add(1));
b(1); // = 3 (and prints 2)
Charles Hughes
Ooo the pipeLog implementation there is pretty cool thanks!
Dimitri Mitropoulos
I have a version of this I use too
const DEBUG_MODE = true;
let debugTimestamps: { [label: string]: number }[] = [];
const debugPipe = (label: string) => <T>(input: T) => {
  if (DEBUG_MODE) {
    debugTimestamps = [
        [label]: performance.now(),
    console.log({ [label]: input });
  return input;
it's basically the same thing, but allows for some recording of timestamps, and then I have a startDebug or endDebug that basically just grabs the debugTimestamps and prints the performance numbers
Hyunseok Oh
how can i make this function in ramda way?
const fn = x => id => R.prop(id, x);
Ian Hofmann-Hicks
Try R.flip(R.prop), that should flip the arguments to R.prop
The C combinator I believe it is called
Ian Hofmann-Hicks
const fn =
flip is very useful when you have to use other libs/apis that are not set up for easy composition with the data last format (or in cases where your data is the key name). But very handy tool in your belt, none the less
Hyunseok Oh
@evilsoft wow thanks
Charles Hughes
@algoshipda you could also use _ which i think is more readable: https://ramdajs.com/docs/#__
so const fn = R.prop(R._, x) I believe?
Ian Hofmann-Hicks
Personally I find the placholders a little less readable than using combinators like flip which provide descriptive names for how the combinator acts on the functions. But I think it is really just a taste thing.
Charles Hughes
Yeah I could go either way in this case. I think for functions that take 3+ arguments though there is little choice
Ian Hofmann-Hicks
also would that x need to be provided, like const fn = x => R.prop(R._, x). and that would loose the nice auto curry that flip would of provided. so you would probably wanna wrap that in an R.curry
Charles Hughes
yah good point
what's other purpose of internal api _arity, except for limiting arguments'length to less than or equals to 10
for being easy to curry the function returned by other functions ?such as compose and pipe
Long Dao
Awww yeah
Ian Hofmann-Hicks
:wave: @longebane how the heck are ya
onDestroy(() => { service.send('DESTROY'); });
how can i write this in ramda?
@kapilpipaliya what are you trying to do
ramda isn't really a language, but more of a utility belt
and in that example, I don't see anything that could take advantage of ramda without seeing more context
Hey, I have one idea.
What if we could do this:
const appendLeft = (arr) => {}
Const appendLeft = (elm, arr) => R.append(elm, arr.reverse()).reverse()
Brad Compton (he/him)
What is the difference between appendLeft and R.prepend?
Is it exists?
Oh i don't no, sorry hehe
Brad Compton (he/him)
No prob! Happy to help :smile:
Pierre-Antoine Mills

Hi all!

I come here to ask you what do you think is the best way to reduce two lists at once?

Supposing that the two lists are exactly the same length, how could I reduce over list1, access the current item (with index usually) and get the value at that same index in list2.

In plain JS, I would usually use the indexfrom the callback, but it see that ramda works differently. I'd like to What do you think?

Rob Grant
zip first, then reduce

someone told me a good practice for composing sorter functions is that if they return 0 it delegates to the next function, i defined this as

const pipeCritera = (...fns) => (a, b) => (fns.find(f => f(a, b) !== 0) || (() => 0))(a, b);

essentially returning the value of the first sorting function that doesnt return 0,

now im wondering if ramda already has this covered

Pierre-Antoine Mills
@robgrant this could double the iteration time on very long lists. Wouldn't it be wiser to have the index provided by the reducer, in that case of repeated operations/long lists?
I wonder what you think about this @Bradcomp