These are chat archives for ramda/ramda

1st
Apr 2015
Ludwig Magnusson
@TheLudd
Apr 01 2015 11:41
Is there a function in ramda creating a list from two arguments?
function(a, b) {
 return [ a, b ];
}
Walle Cyril
@GrosSacASac
Apr 01 2015 12:03
@TheLudd try this
const makeList = function(...x) { return x; };
it also work with more arguments
Ludwig Magnusson
@TheLudd
Apr 01 2015 12:04
I was asking if such a function already exists, in order to not write my own thing. It is not that I can't make it work I was simply wondering if it is already there
And the varardic version prevents it from being curried
Raine Virta
@raine
Apr 01 2015 12:06
curryN(2, ...
Ludwig Magnusson
@TheLudd
Apr 01 2015 12:07
Again, main question is: does it already exist?
Walle Cyril
@GrosSacASac
Apr 01 2015 12:09
makeList = R.curry(function (a, b) { return [a,b];})
I don t think it already exists
those functions return a list
Ludwig Magnusson
@TheLudd
Apr 01 2015 12:13
Yes I checked the documentation also and didn't find anything. But such a function can also be easy to miss, it has happened before so that is why I am asking.
Raine Virta
@raine
Apr 01 2015 12:17
R.unapply(R.identity)(1,2)
Ludwig Magnusson
@TheLudd
Apr 01 2015 12:26
hehe there it was =)
And then just curryN to make it reusable. I'll see if I think it will be worth the effort =)
thanks anyway
Raine Virta
@raine
Apr 01 2015 12:39
wondering what would be a good way to introduce fp friendly higher order functions in a project that is already using normal lodash
Ludwig Magnusson
@TheLudd
Apr 01 2015 12:45
I'd start with something new being built. That could use ramda instead
I don't thing there is an easy solution for such a situation
Raine Virta
@raine
Apr 01 2015 12:52
yep, unfortunately
@jdalton thoughts?
John-David Dalton
@jdalton
Apr 01 2015 14:17
lodash is modular. There's no reason to have to rip out 100% and start over.
Walle Cyril
@GrosSacASac
Apr 01 2015 14:37
haha
Raine Virta
@raine
Apr 01 2015 14:41
damn, after ramda i've come to dislike lodash's mutating side effects
Raine Virta
@raine
Apr 01 2015 14:56
some library i was passing a _.merged object was changing the source object
John-David Dalton
@jdalton
Apr 01 2015 15:04
you can always _.merge({}, obj, other)
Scott Sauyet
@CrossEye
Apr 01 2015 15:50
I think I'm with TheLudd on this. Although there's no technical reason you can't mix-and-match these libraries, I wouldn't do so in the small. If separate components used different libraries, that wouldn't be a concern. But I think it would be confusing to try to work with both APIs In the same small sections of your source code.
Simon Friis Vindum
@paldepind
Apr 01 2015 16:00
@jdalton Sure. You can always wrap a mutating function. But the problem IMO is that you always needs to be on guard and remember which functions mutate and which don't.
John-David Dalton
@jdalton
Apr 01 2015 16:07
There's something to be said for the familiarity with methods like _.merge as it's similar to APIs of the lang, Object.assign, and popular libs, $.extend. This helps with the whole "remember" thing.
Walle Cyril
@GrosSacASac
Apr 01 2015 16:09
I don t understand what you are chatting about ?
Simon Friis Vindum
@paldepind
Apr 01 2015 16:12
@jdalton No, that's not my point it. My point is that you have to remember more. Whenever you look for a function in the documentation you'll have to figure out if it is mutating and if it is find another function. When you're programming in a functional style the destructive functions ends up being noise.
John-David Dalton
@jdalton
Apr 01 2015 16:14

There's over 100 methods, some remembering will be required. The fact that they're based on popular or language methods helps.

I've seen lots of functional examples here that don't make sense until running them in a repl, as well as suggestions for things that simply didn't work the way the user thought. Seems like something, maybe noise too.

Hardy Jones
@joneshf
Apr 01 2015 16:24
I think it's all about perspective
most of the mutating examples given here blow my mind
they're pretty hard for me to understand
for others it's the other way around
the fact that the language defaults to mutability, or that the vast majority of libraries also do, doesn't help me in the slightest.
in fact, it hurts more than it helps
but if mutation and impurity are your norm
then of course it's going to make more sense
but i came here for something else
and forgot it :\
Scott Sauyet
@CrossEye
Apr 01 2015 16:55
Of course, Ramda has made immutability one of its main principles. And there aren't that many mutating lodash functions.
So it's not too hard to avoid them.
But, as always, it's important to note that Ramda is designed to support a different style of coding than is lodash.
Walle Cyril
@GrosSacASac
Apr 01 2015 18:05
I am searching an internationalisation library for client side, what do you recommend ?
Alex Bepple
@alexbepple
Apr 01 2015 23:17
In case it’s helpful to others: I have created a Dash docset for Ramda. It’s an adaptation of the online docs.
A couple of screenshots: https://github.com/ramda/ramda/issues/995#issuecomment-88659447