These are chat archives for ramda/ramda

24th
Oct 2017
Andrzej Lichnerowicz
@unjello
Oct 24 2017 04:34
@Bradcomp hey! thanks a lot! One question tho... I see that binding .bind(Promise) somehow works around an error that promise rejection is unhandled, but I fail to come up with reason why.
oops. sorry... that is an actual error that Object is not a constructor... disregard this, I shouldn't be typing at this hour apparently :)
Philipp Wille
@Yord
Oct 24 2017 08:17
@MateuszTrN How about
const createFilter = o(
  filter,
  useWith(unapply(allPass))([
    propEq('prop1'), 
    propEq('prop2')
  ])
);
I like the parameterized version better, though. The pointfree version is harder to understand in my opinion.
Philipp Wille
@Yord
Oct 24 2017 09:08
In this particular case, unapply(allPass) could be substituted with both, though, which is a little bit cleaner.
MateuszTrN
@MateuszTrN
Oct 24 2017 09:30

@Yord thank you! I ended up with:

const createFilter = compose(
  filter, 
  useWith(
    both, 
    [ 
      propEq('prop1'),
      propEq('prop2')
    ]
  )
);

I'm pretty newbie with ramda (and functional programming too), so please forgive me if my question is to trivial, but... is there any advantage of using o instead of compose in my case?

Philipp Wille
@Yord
Oct 24 2017 09:38
Actually, your solution is correct, while mine is not (did not see that earlier). Here is why: o is the curried variant of compose with exactly one argument. createFilter however takes two arguments. So compose is the right choice here! :)
Apart from that: I like to use o in cases where you compose exactly two functions and have exactly one argument. It serves two purposes: Knowing o takes exactly one argument makes your code easier to understand and inlining o makes your line shorter.
But these reasons are a matter of taste.
MateuszTrN
@MateuszTrN
Oct 24 2017 09:58
@Yord Thank you again for valuable lesson :)
Michael Hurley
@buzzdecafe
Oct 24 2017 12:05
@MateuszTrN @Yord could you use whereEq for that filter? e.g.
const createFilter = filter(whereEq({prop1: prop1, prop2: prop2}))
?
Philipp Wille
@Yord
Oct 24 2017 12:27
@buzzdecafe Nice, I wasn't aware of whereEq :). Very convenient! An improved pointfree version with whereEq could then be:
const createFilter = compose(
  filter,
  whereEq,
  unapply(zipObj(['prop1', 'prop2']))
)
MateuszTrN
@MateuszTrN
Oct 24 2017 14:02
@buzzdecafe cool stuff ;) thank you both guys!
John Whiles
@Jwhiles
Oct 24 2017 14:33
Can I safely that if I use ramda's mergeDeepRight objects I pass into it won't be mutated?
Philipp Wille
@Yord
Oct 24 2017 14:37
Yes. Internally, mergeDeepRight calls mergeDeepWithKey which calls mergeWithKey which creates a new object and then assigns new properties to it.
John Whiles
@Jwhiles
Oct 24 2017 14:50
great. Thanks
Kurt Milam
@kurtmilam
Oct 24 2017 15:31
Any thoughts here on the points brought up in this article?
Jonah
@jonahx
Oct 24 2017 19:29
@kurtmilam My thought is that he raises valid points, but the benefits of declarative code are at least an order of magnitude more important than those of clean stack traces. Of the possible solutions offered, only improvements at the library level or switching to a full type system make sense to me.
Brad Compton (he/him)
@Bradcomp
Oct 24 2017 19:29
That's interesting. I have seen some pretty unhelpful stack traces with Ramda, but to be fair I've seen them elsewhere as well. I do think that better stack traces should be on our radar though
Brad Compton (he/him)
@Bradcomp
Oct 24 2017 19:34
:point_up: I agree. I find it's in general still easier to debug my code, even though we occasionally get a crummy stack trace.
Matthew Willhite
@miwillhite
Oct 24 2017 19:37
When presenting Ramda to a colleague, all feels great until we get that stack trace. However it does present an opportunity to explain the data pipeline and how we can use tools like tap to peak inside the pipeline.
Robert Mennell
@skatcat31
Oct 24 2017 21:36
@kurtmilam He has some downfalls in that article. He also has one really good piece of advice: Don't go overboard with pointfree. I didn't really see where he said you "shouldn't", but I did notice him saying "be careful"
Robert Mennell
@skatcat31
Oct 24 2017 21:47
I'm curious of there is a way for us to use tap if a certain variable is set... Like only tap if debug enabled or something?