These are chat archives for ramda/ramda

21st
Jan 2019
Just RAG
@justrag
Jan 21 10:53
A recommendation request, sorry if it's a bit too general: I'm writing a board game (to simplify, imagine checkers, but instead of a regular checker gamepiece you have pawns in 3 different sizes which you can also lay down pointing in one of the 8 directions). Can anyone suggest a good data structure for the game board that would make it easy to write the moves as Redux reducers?
Just RAG
@justrag
Jan 21 11:36
Should I just go with a 2d Array of objects or is there a better way?
dfinucane
@dfinucane
Jan 21 17:38
I am new to ramda and functional programming. I am excited to use functional composition. I am struggling a bit. I have a sequence of functions I want to pipe together some of which return a Promise. I was planning to use pipeP but now I see that it has been depricated in favor of pipeWith. I want to be sure I understand why. Was this done to simply generalize the function so that ramda didn't have Promise specific code. If that is the case then all i need to do is implement my own pipeP that is implemented using pipeWith. Am I understanding this correctly?
Ben Briggs
@ben-eb
Jan 21 18:31
@dfinucane Essentially, yes. For further reference check out ramda/ramda#2512 and then ramda/ramda#2515 - the difference being that pipeWith(then) takes an array of functions as opposed to pipeP which is variadic
@dfinucane pipeWith is more generic also whereas pipeP is specialised to Promise
Ben Briggs
@ben-eb
Jan 21 18:37
@justrag What kind of API do you mean by 'easy to write the moves as Redux reducers'?
dfinucane
@dfinucane
Jan 21 18:37
thanks @ben-eb
Ben Briggs
@ben-eb
Jan 21 18:37
You're welcome :)
@dfinucane I think also it's nicer to write pipe(syncFn, syncFn2, then(asyncFn)) in that you don't have to write pipeP(x => Promise.resolve(x), syncFn, syncFn2, asyncFn) - so Ramda 0.26.0 cleans up async/sync composition from 0.25.0
dfinucane
@dfinucane
Jan 21 19:33
that makes sense @ben-eb
Ben Briggs
@ben-eb
Jan 21 19:33
:smiley:
dfinucane
@dfinucane
Jan 21 19:35
can i also do this pipe(then(asyncFn1), syncFn, then(asyncFn2)) @ben-eb
that doesn't make sense does it. the first function returns a promise and the syncFn can't have that as an argument
Ben Briggs
@ben-eb
Jan 21 19:39
@dfinucane Sorry, I didn't test before writing :) You would pipe as normal until you encounter a promise returning function
const asyncFn1 = x => Promise.resolve(x + 1)
const asyncFn2 = asyncFn1
const syncFn = x => x + 1

pipe(syncFn, asyncFn1, then(syncFn), then(asyncFn2))(0)
  .then(console.log)
Returns 4
dfinucane
@dfinucane
Jan 21 19:41
oh ok. i need to try that out so i can understand it. thanks
dfinucane
@dfinucane
Jan 21 19:43
thanks. i'm embarrassed to ask but when using the repl how do i invoke it. so if i make a change i don't know how to reinvoke
never mind. its automatic
Ben Briggs
@ben-eb
Jan 21 19:44
Yep :)
dfinucane
@dfinucane
Jan 21 20:07
if asyncFn1 can fail and there is no useful default how can i handle that in Ramda? i guess this question has nothing to do with sync/async. i have seen using the Either monad shown as a way to get at the reason for the error without invoking the remaining functions in the pipe. does Ramda have a built-in way to do that or should i bring in another library with an Either implementation
Ben Briggs
@ben-eb
Jan 21 22:19
@dfinucane If you're comfortable with monads you may want to try sanctuary instead; see https://sanctuary.js.org/#ramda for the differences