ramda/ramda

Practical functional Javascript

Long Dao

@longebane

that's essentially what I'm getting at

Brad Compton (he/him)

@Bradcomp

JS is a multi-paradigm language supporting OO, Functional, and Imperative programming styles, as well as allowing the user to mix and match

Long Dao

@longebane

deja vu. I feel like I've seen that before

Ian Hofmann-Hicks

@evilsoft

:+1: to that @Bradcomp

Long Dao

@longebane

looks great!

Ian Hofmann-Hicks

@evilsoft

:sheep: :it:

Long Dao

@longebane

:red_circle: :eyes:

Brad Compton (he/him)

@Bradcomp

Because of this, it can support a wide variety of applications and use cases. It also provides a number of footguns for users that await the incautious developer.

Long Dao

@longebane

footgun?

Brad Compton (he/him)

@Bradcomp

It will pretty much let you do anything and won't try to stop you

Long Dao

@longebane

traps?

Brad Compton (he/him)

@Bradcomp

Leading to a number of ways to shoot yourself in the foot

self sabotage

:stuck_out_tongue_closed_eyes:

Long Dao

@longebane

yeah. good stuff. thanks my brah's

Ian Hofmann-Hicks

@evilsoft

Anytime! Is your course going to be public?

Carl Parrish

@carl-parrish

I have an object {} my object may have several nested properties.
const myObj = {prop1: {prop2: {prop3: data: null}}}
I need to set data if it's empty

 if ( R.isNil(myObj.prop1.prop2.prop3.data))
  {
     myObj.prop1.prop2.prop3.data = myCurrentDataObj ;
 }

This works as long a prop1, prop2 & prop3 exists. But sometimes they don't so I tried

If (R.isNil(myObj.prop1)){ myObj.pro1 = {prop2: {prop3: data: {}}}; }

Do I actually have to explicitly check to see if every property has been defined before I can set data? I was hoping that something like R.lensProp and R.set could solve this for me but if so I haven't figured it out yet.

Brad Compton (he/him)

@Bradcomp

Look at R.pathSatisfies

and other similar functions

Carl Parrish

@carl-parrish

thanks

Brad Compton (he/him)

@Bradcomp

const dataPath =  ['prop1', 'prop2', 'prop3', 'data'];
when (
  pathSatisfies(isNil, dataPath),
  assocPath(dataPath, {})
)(myObj);

assocPath will create intermediate properties I am pretty sure

Carl Parrish

@carl-parrish

will try that now.

Brad Compton (he/him)

@Bradcomp

also change out the {} with myCurrentDataObj

and it won't update your input, but instead create a new object based on the old one

Carl Parrish

@carl-parrish

but only if it was nil right?

Brad Compton (he/him)

@Bradcomp

If pathSatisfies returns false (the property isn't nil) then it will just return myObj unchanged

dimatter

@dimatter

hey all. what is wrong with the following? const previous = R.defaultTo([0,0], R.nth(-1))

when calling it with an empty array I was expecting the defaults

Riku Tiira

@rikutiira

@dimatter you are checking default of a truthly value (a curried function returned R.nth(-1))

You could do R.compose(R.defaultTo([0,0]), R.nth(-1))

Ben Briggs

@ben-eb

Ooo, I hadn't used sortWith before, that's better still :)

pentatronix

@pentatronix

How would one traverse with a lensPath? I have been trying to wrap my brain around partial.lenses for a while and I get nowhere :(
What I would be after is the equivalent to x = lensPath(['a', *, 'd']); which would return all d children of any elements that are children of a.

Twizzes

@Twizzes

const obj = { a: [{ d: 1 }, { d: 2 }, { d: 3 }] };
const aChildrenD = R.pipe(R.view(R.lensProp("a")), R.map(R.view(R.lensProp("d"))));

console.log(aChildrenD(obj));
// => [1,2,3]

this only works if a can be operated on by R.map

@pentatronix

pentatronix

@pentatronix

@Twizzes , ah makes sense. So effectively you build up lenses of the sub objects, and wherever you need to you just compose with map or reduce etc.

pentatronix

@pentatronix

Thanks. I had not seen a particularly clear usage for lenses, especially in complex read only situations.

Alex McKay

@alexandermckay

I am trying to a find a function in the ramda library that does the same thing as the callback helper function I have written below. Could someone please let me know if it exists?

const callback = (fn) => (...args) => () => fn(...args)

const obj = {
  method: (x, y) => x + y
}

const exists = always(has('method', obj))
const execute = callback(prop('method', obj))('Invoke ', 'Fn')

when(exists, execute)(null)

Brad Compton (he/him)

@Bradcomp

https://ramdajs.com/docs/#thunkify

@alexandermckay That might be what you are looking for.

However, your version looks fine too

Alex McKay

@alexandermckay

You're a legend, thank you

Ben Briggs

@ben-eb

Hi friends. I've got some push back from our team about functional stuff and wondered if you had any advice. Specifically some of our team are struggling with currying, I think this may have been exacerbated because we are using a lot of closures to do dependency injection. Do you have any advice on how I could teach this stuff or any debugging patterns that may have helped you out? I do understand some of that pain and wonder if it might be reasonable to try out typescript, though I have seen posts here about typing pains with ramda in the past. To be honest I really like the flexibility of dynamic types but static typing does have good developer ergonomics (especially for a developer trying to extend some unfamiliar code)

I think sometimes I might struggle with the why of FP nowadays because it's kind of instinctive to me. And I'm conscious that I need to surface those things too because I'm essentially leading the charge of FP at our work

Ben Briggs

@ben-eb

I am also worried that in order to get the benefits of FP we might need to go further down the rabbit hole (e.g. algebraic types and especially Futures - so that we can end up with more loosely coupled units) and I might alienate people. I guess I need to find balance :slight_smile:

Brad Compton (he/him)

@Bradcomp

I would push for ADTs over currying for sure. Point free without static types can make things harder to read until used to it. It's really nice if your team is into it, but otherwise I think it's best used sparingly. There are certain places where currying makes a ton of sense (DI is often one of those cases).

I can't tell you how often I see a good use for Maybe or Either. They come up everywhere, and are especially helpful in dynamically typed code.

You can use them in a fairly non-FP codebase. Function returns an Array or undefined - use Maybe. Need to return error results from a function - use Either. Once the value of those are established bringing in Futures will be a bit easier.

Ben Briggs

@ben-eb

Thanks @Bradcomp :) Yes, DI is a pain point right now. Personally I like hiding things like vendor SDKs inside a closure so it makes testing units easier, but I think this adds too much complexity when the same result could be done by using structures such as Future and composition rather than injection.

I don't think pointfree necessarily is adding pain, the problem seems to be in the amount of passing around functions, and because some of these functions have to handle side effects we end up with a lot of (arg1, arg2) => async () => { ... }

Where communities thrive

People

Repo info

Activity