assocPath will create intermediate properties I am pretty sure
and it won't update your input, but instead create a new object based on the old one
when calling it with an empty array I was expecting the defaults
You could do
R.compose(R.defaultTo([0,0]), R.nth(-1))
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
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.
this only works if
a can be operated on by R.map
@pentatronix
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)
@alexandermckay That might be what you are looking for.
However, your version looks fine too
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
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:
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.
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 () => { ... }
I am working on some material about taking imperative code into functional and extending that into ADTs when the requirements change. e.g. start with input as always a string, then we add null, then we add a string of a different shape, and contrasting the approaches on a very small unit of code.
So for instance one pattern you might use in imperative is early return, but that doesn't compose well (which is when you might reach for Maybe)
I was gonna say, starting small can help. Show how to deal with a bunch of if statements using Maybe or Either. Show how currying a single function can give you a bunch of different functions. The place I think currying really helps is if you need to partially apply a function against an array of values (think vectors and the like)
or good examples
But yeah,
ap is a great use case for curry except that it relies on the understanding of uh... container types
Both times I've taken some anonymous lambda and wrapped a ramda function around it, then progressively refactor it until it's fully declarative
const f = when(x => x === 2, x => x + 1);
const f = when(eq(2), x => x + 1);
const f = when(eq(2), inc);
But both ramda & lodash offer good stories for data manipulation