Hi!
this is normal code? o use Ramda better?
o => o.selected could be R.prop('selected') I guess.
and I'd suggest using
R.pipe or R.compose instead of data => ...(data)
Thank you very much :)
No problem :relaxed:
@manniL I'm not sure if it's better (it's probably not as easy to grok) but I had a go at your earlier question:
const isShiftAction = propEq('shift', true); const isNotShiftAction = complement(isShiftAction); const appendTo = flip(append) const willBeUsedAsReduceFunction = shifts => ifElse( both( compose(isShiftAction, head), compose(isNotShiftAction, last) ), compose(appendTo(shifts), head), always(shifts) ) willBeUsedAsReduceFunction([])([{ shift: true }, {}])
@ben-eb Just tried out your proposal :relaxed:
But the arity of the reduceFunction doesn't fit (it seems)
console.log(reduce(willBeUsedAsReduceFunction, [], [{shift: true}, {}])) returns a function
I can return the value property?
is
getActive(types) an object?
(with the value prop)
const get = pipe(find(prop('selected')), prop('value'));
this.setState({
types: get(types),
addresses: get(addresses),
...
})get is a terrible function name, so change that to suit your app. Also, there's no error handling, in case the results of find is undefined.
🤠 EEEha!
With Advent of Code, I'm increasingly going pure JS without ramda, just for the perf benefits. Ramda is slooow! For example, over here, code with ramda took over a minute and a half, while the pure JS version took about 2 seconds to execute.
I think the culprit is all the
.reduce calls that happen behind the scenes with every composed (pipe/compose) function's invocation.
I wonder if there's any way, maybe using a build tool, to figure out what the code is supposed to do, and rewrite it to be more optimised. After all, with Ramda or FP in general, we're declaring intent and flows, not actually writing imperative code, so it should be possible to have tooling to understand that intent, and then optimize for performance/size.
That's hard with JS I guess
Facebook has been working on a thing called Prepack https://prepack.io/ which seems closest to what I'm talking about. But I'm not sure how far along it is. My guess is, it should really help code written in Ramda, or functional code in general.
Well, it'll "just" pre-compile stuff. So it'll still take the same time
@rakeshpai: I've been using a mix of Ramda and vanilla JS all along. But a linked list like that is inherently stateful, and Ramda is certain to be non-optimized in an extremely stateful system.
Have you guys seen (unsure if it fits this use case, but worth mentioning): https://github.com/funkia/list
I'm not sure what use-case you're talking about, but
list is great. It was created by @paldepind, a Ramda core team member and contributor to FantasyLand, as well as the creator of Flyd.
I've been using it a bit in my own projects, although I haven't yet introduced it at work.
Thanks, @manniL and @CrossEye. It doesn't look like Prepack is doing what I thought it does. I'd have expected this entire program to be 'down-converted' into one console.log line.
(That code is from a talk I'm giving soon at a local meetup here. The talk is a live-coding thing, giving the audience a gentle introduction to Functors and Monads. Any feedback about the code is welcome!)
@manniL You can use
uncurryN to remove the manual currying there - so uncurryN(2, willBeUsedAsReduce)
@ben-eb Oh, nice! Thank you :relaxed:
:+1:
@rakeshpai: Note that in that code, your Maybe is not entirely fantasy-land compatible.
1.i No parts of
ashould be checked
-- Applicative's of method.
This is because it wants to allow
Just(null) as a legitimate value.