These are chat archives for ramda/ramda

12th
Sep 2016
Craig Dallimore
@craigdallimore
Sep 12 2016 10:26
@joaomilho Ion looks very cool but I'm not sure why I'd choose it over Elm / Purescript
James Grayling
@jamesgrayling
Sep 12 2016 11:21
@joaomilho Ion looks cool!
Risto Novik
@riston
Sep 12 2016 12:05
What are additional libraries to use with Ramda? I know Sanctuary plays nicely with ramda.
Michael Hurley
@buzzdecafe
Sep 12 2016 12:38
@riston any lib that implements fantasy land types should play well
Michael Hurley
@buzzdecafe
Sep 12 2016 12:57
ntasyland/fantasy-land/blob/master/implementations.md
Craig Dallimore
@craigdallimore
Sep 12 2016 13:26
@joaomilho - that wasn't intended in a mean way :)
Juan Lulkin
@joaomilho
Sep 12 2016 13:29
sure @craigdallimore
my reasoning is this: there are 2 kinds of langs that transpile to JS
Elm / Pure / Cljs for instance, they are different languages altogheter
then you have interop w/ JS made more difficult, and you deal w/ it w/ FFI or somethin'
while Coffeescript tries to be only a simple wrapper, where you can look at the code and still see the JS behind (at least this is the promise :D)
you can import JS into it and import coffee into JS easily
so ion also works like that, so you don't have to rewrite/wrap existing JS langs into it
and it is not really away from JS, it just makes using Ramda more natural
and finally, it's still just a toy language, so I wouldn't tell you to use it instead of Elm anyway :D
the main reason I've found at work, is the people are put of for having to use functions for ops
Juan Lulkin
@joaomilho
Sep 12 2016 13:34
like in map(mult(5), range(1, 9))
so it just adds some sugar on top of it: map(*(5), [1..9])
Robin Wenglewski
@rweng
Sep 12 2016 14:37
Guys, I would like to know your opinion on the following matter: I have this class, which I am rewriting to a more functional style. After doing this, I have multiple functions with the same signature: (account: BankAccount, state: AppState) => AppState. account is basically the configuration object for the methods, while state is the date they operate on. Some function even have a third parameter which is the BankTransaction. Now I have the choice between grouping them with a function that accepts account and returns the functions basically curried, so that they use the account from the closure and only have state as parameter. Or I could write a "service class", which has account as constructor parameter, never mutates it and the methods it provides accept state and return state. Or I could just keep them plain functions, but then I have to respecify the parameters or have many partial applies. How do you handle cases like this?
Keith Alexander
@kwijibo
Sep 12 2016 14:58
@rweng partially-applying the most common parameters, so that the final parameter is the one that varies most, seems like a good first option
@rweng fwiw, I enumerated the various options I could think of for this sort of scenario a few days ago: :point_up: September 8, 2016 6:52 PM
Robin Wenglewski
@rweng
Sep 12 2016 15:06
thanks @kwijibo , now I got a forth possiblity, a Reader, which I still have to get to know ;) What I don't like on the partial application / dependencies via parameters approach is that is seems to be a lot more verbose than having the configuration in the closure / class
Keith Alexander
@kwijibo
Sep 12 2016 15:07
@rweng I think the best option will depend on how you want to use the functions, and at what point you can provide the arguments
an advantage of dependencies as parameters is that generally it is easier to write tests; you don't need to setup classes each time, or worse, rewire the dependencies
but it can get horribly verbose
what I've been doing is lumping all the dependencies into a pojo which I partially apply as the first parameter. ES6 Object destructuring makes this a bit less painful
Robin Wenglewski
@rweng
Sep 12 2016 15:12
@kwijibo well, the configuration is loaded once from the backend and then multiple methods are executed with it. Testability, as well as optimization (tree-shaking etc) are definitely on the pro side for plain functions, but I still tend to closure or class since s.th. like this withAccount(account).someMethod(state)is I think also quite well testable
and yeah, you probably could even use destructureing quite nice like const {someMethod, someOtherMethod} = withAccount(account)
Keith Alexander
@kwijibo
Sep 12 2016 15:16
because you can do something like
const env = {
  dbRead, dbWrite, user, config, foo, bar
}
const readPayment = ({user, dbRead}) => paymentID => //...
const  updateProfile = ({user, dbWrite}) => updatedUser => //...
Robin Wenglewski
@rweng
Sep 12 2016 15:18
hmm, well my use-case is a bit different, I was thinking of doing s.th. like this
function withAccount(account) {
  return {
    method(state) { return account },
    otherMethod: (param) => param + account.id
  }
}
I guess its basically the same thing
Robin Wenglewski
@rweng
Sep 12 2016 15:23
Still, it reduces boilerplate a bit, which with TypeScript is even heavier :/
and it allows withAccount to check some preconditions on account. Yeah, guess I'll go with this approach. Thank you @kwijibo!