These are chat archives for ramda/ramda

26th
May 2017
Jason Shin
@JasonShin
May 26 2017 10:28 UTC
@gabejohnson @i-am-tom thank you both for helping me out =)..
I have another question (I'm super awesome fan of Ramda and FP in general). https://github.com/Biphub/BipHub/blob/master/core/actions/bip_actions.js#L42
That's my open source project that I am working on at the moment. I would love to be able to compose those lines of code using Ramda's compose but not sure how would you go about it.

So ideally my could would look like

R.compose(
 R.head(incomingAction).get('id'),
 app.related('incomingActions')
 models.App.findOne
)

or I guess I can use
() => {} to wrap each of those compose steps

I heard from my friend if I want to be able to compose these promises, I must convert them into Future and expose .fork()
how would you approach this?
=)..
Jason Shin
@JasonShin
May 26 2017 10:34 UTC
I was so happy to convert one of legacy code at work using @i-am-tom and @gabejohnson recommendations of composing immutable js map
I almost cried when I looked at my code which is so declaritive
and so readable and predictable
x => y
Tom Harding
@i-am-tom
May 26 2017 10:49 UTC
async/await actually causes problems when you come to composition
I’d take a look at composeP in Ramda - might be what you need
Ideally, though, you want a sequential async type (monads, anyone?) for real beauty
Jason Shin
@JasonShin
May 26 2017 11:09 UTC
I'm happy not to use async / await
as long as I can use ramda compose
should I convert all my promises into Future?
Tom Harding
@i-am-tom
May 26 2017 11:10 UTC
You don’t have to do anything so radical just yet; getting composeP working will at least show you the flow, and then it’s just a case of swapping Promise to Future and composeP to composeK
Denis Stoyanov
@xgrommx
May 26 2017 12:34 UTC
Promise.all => async, sequence(Promise.of) => sync
Otto Nascarella
@ottonascarella
May 26 2017 18:54 UTC
Ramda family, here is a question for you guys...
...I've been testing R.lensPath vs R.assocPath...it is just the same speed.
What would be the advantages, besides the possibility of functional composition (which already is an huge vantage) for using lenses.?
Rick Medina
@rickmed
May 26 2017 19:12 UTC

functional composition

isn't that enough advantage?? :)

Otto Nascarella
@ottonascarella
May 26 2017 19:15 UTC
@rickmed well, yes it is! but I am trying to see what else people come of with... clever people, these functional programmers ;)
also...I find that if you think of monoids as "composable"...then its like you have a path for assoc (array) that you can compose (concat) with another path... don't you agree?
Tom Harding
@i-am-tom
May 26 2017 19:38 UTC
@ottonascarella Function composition is absolutely a monoidal operation, where empty = x => x :)
Otto Nascarella
@ottonascarella
May 26 2017 19:44 UTC
@i-am-tom don't you agree if you "squint" a bit, array could be seen as a monoid too, so instead of thinking of composing the functions (lenses) you could compose the arrays (paths) so...at the end...kinda equivalent using either...
unless someone else thinks of a special reason to use lenses....
well...I just thought of one good reason:
const myLens = R.lens( 
immutable => immutable.get('something'),
(val, immutable) => immutable.set('something', val)
);
Georgi Angelov
@GeorgiAngelov
May 26 2017 20:28 UTC

Hey guys. So I have an issue where I have an array of futures, and I need to fork each future and collect the results and the rejects.

Before:

{
  '2': {
     '00005424': Future { _fork: [Function] }
   },
  '3': {
     '00005429': Future { _fork: [Function] },
     '00005424': Future { _fork: [Function] }
   }
}

After:

{
  '2': {
     '00005424': {"data_from_future_after_resolve/reject": "..."},
   },
  '3': {
     '00005429': {"data_from_future_after_resolve/reject": "..."},
     '00005424': {"data_from_future_after_resolve/reject": "..."}
   }
}

So the issue here is to resolve this in an immutable way and not have some global accumulator. We can't simply return the data from the Future since we have the callback which causes the problem.

I would appreciate any help with this!

Michael Rosata
@mrosata
May 26 2017 20:28 UTC
@GeorgiAngelov have you looked at http://ramdajs.com/docs/#traverse ?
Michael Reinig
@MReinigJr
May 26 2017 20:32 UTC
@mrosata I think that will cause a single reject to cause all to fail correct? I think he wants the resolve/reject data to be imbedded in the data structure. It may be better to rebuild the desired data structure while forking the Futures? What do you think?
Rick Medina
@rickmed
May 26 2017 20:54 UTC
use traverse and "recover" the failed futures mapping over the left side (many libs have "orElse" or equivalent functions) within the traverse fn
Julio Borja Barra
@juboba
May 26 2017 22:43 UTC

is there a way to create a function that receives to params from something like:

const findById = find(where({ id: eqBy(toString, _____) }))

findById('firstId', collection);

(I wanted to say two params)
Brad Compton (he/him)
@Bradcomp
May 26 2017 22:45 UTC
R.useWith
can help if you really want Point Free
Julio Borja Barra
@juboba
May 26 2017 22:46 UTC
yeah, pointFree is my messiah
wow, this is hard...
Julio Borja Barra
@juboba
May 26 2017 22:51 UTC
don't know where to put the useWith
Brad Compton (he/him)
@Bradcomp
May 26 2017 22:55 UTC
one sec
ugly tho
Julio Borja Barra
@juboba
May 26 2017 23:00 UTC
ohhh