These are chat archives for ramda/ramda

Jul 2017
Ian Hofmann-Hicks
Jul 27 2017 03:56
I would say it is not. You typically call fork at the edge of your program, when you want to run side effect. I would say that would be the BEST place to run your IO and I am unanimous in that
Not a bad idea. It is not a bad idea.
Ian Hofmann-Hicks
Jul 27 2017 05:03
But one thing to keep in mind, typically the input to IO is fixed at Unit IO () a so if you care about the value that resolves with your Future you may have to do some silly things to inject that value and subsequently run your IO something like this siggy applyAndRun : IO b -> a -> b. Does that make sense? That is how I understand it, but I may be totally off base.
Jul 27 2017 10:36
@Bradcomp It worked perfectly. Thanks! Btw, how does one think like that?
Julio Borja Barra
Jul 27 2017 11:08

hey guys, any ideas on how to refactor this?

const getCommentFields = (body, reply_to) => pipe(
  pick(['author', 'text']),
    assoc('parent', reply_to)

I hate using always for this kinds of stuff...

Jul 27 2017 11:37

@Bradcomp Hey Brad, I want to update an Object inside a List of Objects and return the updated List. This code below is exactly what I want :

const updatedCat = category
  (acc, curr) =>
    R.equals(curr._id, updatedCat._id)
      ? [...acc, R.merge(curr, updatedCat)]
      : [...acc, curr],
  [], categories

Thanks :)

Kurt Milam
Jul 27 2017 11:43
@jonathandion looks like a good candidate for lenses.
Jul 27 2017 12:53
@Bradcomp The code above is an another question : How can I refactor this code? For yesterday question, mergeAll return an Object no an Array. I’m expecting [{a: 2}, {b : 2}] Thanks for the feedback.
Jul 27 2017 13:27
Especially in Javascript, I think it's safe/reasonable to skip using use the IO monad if you're forking. You're almost always sideEffecting with .fork. If you happen to have an IO structure you'd like to reuse, great. But since your intent will almost always be to run that side-effect immediately, there's less to be gained there otherwise other than extra verbosity. On the other end of things, doing a natural transformation from IO to Task is also dead simple, so if you have an IO effect that needs to kick off something that needs to then wait on a continuation before chaining on another effect, it's reasonable to transform into Task and then just do the effect in the fork, instead of transforming back into IO (because you're not going to be able to easily compositionally chain further IO effects on later at that point: but you can still chain on additional Tasks before that final fork)
If you fork a Task, you're probably not returning the computation anywhere without a side-effect. So unless your side effect is to build up and save a stored effect that you intend to run later, you're probably overcomplicating things.
Which isn't to say that that's not a crazy idea. I could see an operation that 1) causes an effect 2) then uses some async process to get some data that will be relevant to a LATER effect you intend to run 3) use a side-effect to store the final (but still unexecuted) IO effect itself in something like a redux store
Bijoy Thomas
Jul 27 2017 13:58
@jonathandion R.compose(R.of, R.mergeAll, R.concat )([{ a: 1},{b : 2}], [{ a : 2}]) .. just wrap the result of mergeAll into an array with of
Jul 27 2017 15:00
@kurtmilam looks exactly like what that's for
too bad no lens in the cookbook
Ian Hofmann-Hicks
Jul 27 2017 17:00
@dtipson good call. I agree with that :100:
Brad Compton (he/him)
Jul 27 2017 17:25
@IsaacRaja_twitter Glad it worked! I generally try to take each piece and break it up as far as I can, and run through the potential results. This can lead to better insight into how to put it all back together.
@jonathandion Thanks for the update. I'll take a look
Brad Compton (he/him)
Jul 27 2017 17:31
const updatedCat = category;'_id', updatedCat), R.merge(R.__, updatedCat)), categories);
@jonathandion When you need to update a single value in a list, I will typically use map(when(...)). When will only run the function if the predicate returns true. In this case, it will return each item untouched, except when the ID's match, and then it will merge the old with the new.