const asyncCompose = (f, g) => x => { const a = await g(x); return f(a); } and use this but it doesn't really have benefits over promises. It's just a syntactic sugar for promises and it's strictly for imperative code so no much benefit from using it in "ramda-code". Even worse, promises are at least objects and data so it's easier to deal around them in functional code.
callFuncWithArgs(
nthArg(1),
nthArg(2),
)(null, 3, a => a * a) // 9
call if you swap around the nthArgs. Not sure which I prefer
I thought maybe this doc is not reflective of exception safety
once
Accepts a function fn and returns a function that guards invocation of fn such that fn can only ever be called once, no matter how many times the returned function is invoked. The first value calculated is returned in subsequent invocations.
But actually not bad 🤔 seems to behave as stated:
let onceSubjectCallCount = 0;
const onceSubject = (doThrow=false) => {
onceSubjectCallCount++;
if (doThrow) throw onceSubjectCallCount
return onceSubjectCallCount;
}
const onceSubjectOnce = R.tryCatch(
R.once(onceSubject),
R.identity
)
const result = [
onceSubjectOnce(true),
onceSubjectOnce(true),
onceSubjectOnce(true)
]
result // [1, undefined, undefined]:clap:
TypeError: g.call is not a function
at node_modules/ramda/src/internal/_pipe.js:3:14
at node_modules/ramda/src/internal/_arity.js:11:19
import withRouter from 'next/router';
import { Head, UserInfoAndNavigation, WithAuth, WithLogs, Error } from 'components';
const enhance = (R.compose(withRouter, WithAuth, WithLogs) as any);
// WithAuth
export default ComposedComponent => {
class Component extends React.PureComponent<IProps> { }
return connect(mapStateToProps, mapDispatchToProps)(Component);
}
//WithLogs
export default ComposedComponent =>
class extends React.PureComponent { }Test suite failed to run
TypeError: g.call is not a function
123 | };
124 |
> 125 | export default connect(mapStateToProps, mapDispatchToProps)(enhance(WithRouterGlobalLayout));
| ^
126 |
at node_modules/ramda/src/internal/_pipe.js:3:14
at node_modules/ramda/src/internal/_arity.js:11:19
https://github.com/ramda/ramda/blob/master/source/internal/_pipe.js
Here is the offending code. g will take on the values of WithAuth and WithRouter over the course of executing enhance. I am assuming both of those are Functions and thus have a call method on them, but we can verify that experimentally too.
Does this code fail when running outside a test harness? If not then Jest could be messing with the prototypes or something.
If so, then we can try removing first one and then the other of those two functions from enhance and see if either way fixes things, or else just try WithAuth.call(WithAuth, component) and the same for WithRouter
this?
Cannot read property 'x' of undefined
I was reading this article on medium "Understanding Functor and Monad With a Bag of Peanuts," that says
- associative law
...Functor[X].map(f).map(g) == Functor[X].map(x => g(f(x))
This law allows us to chain map function calls instead of composing multiple functions and then applying them in a single map operation.
As a contrived example, I think the 2nd version extractPath2 could use a lot more memory on some inputs:
const parse = R.tryCatch(JSON.parse, R.always(null))
const viewPath = R.compose(R.view, R.lensPath)
const extractPath1 = path => R.map( R.compose(viewPath(path), parse) )
const extractPath2 = path => R.compose( R.map(viewPath(path)), R.map(parse) )The medium article, maybe it's only to say the 2 extractPath functions yield the same result, without comment on runtime performance.
Or is it suggesting that a fp language runtime might take advantage of this "associative law" to rearrange equivalent compositions as an optimization?
Does ramda do anything with this code beyond naive expectation on reading it?
tempB = map(viewPath(path), tempA) and tempC = map(parse, tempB). Yes, true fp language can optimize it (though maybe not. For example, such an optimization would make not much sense in haskell -- with laziness both cases work in the same way). No, ramda doesn't do it for you, it's your job as a developer to see there are n functions in a composition wrapped by map and it can be replaced with map of composition. Ramda however supports transducers, lazy by design, so you can write in this style to exlude any possibility for a mistake.
Interesting... just looked at the changelog and it was 0.25 that actually updated the behavior. ramda/ramda#2319
It definitely works in the most recent version: https://ramdajs.com/repl/#?prop%28%27a%27%2C%20undefined%29
@damrem You can put the version in the docs URL like this: https://ramdajs.com/0.25.0/docs/
We should make that documented or easier to discover.
const getter = always(undefined)
const setter = (a, b) => b
const emptyLens = lens(getter, setter)
view(emptyLens, "anything") // undefined
set(emptyLens, "anything")(12) // 12
1 reply
And if so, how do I learn and how long did it take you?
import R from 'ramda'
import scores from './scores.json'
const reviewCreditScores = R.map(
R.cond([
[R.lte(800), R.always(`${'value'} is excellent`)],
[R.lte(700), R.always(`${'value'} is good`)],
[R.lte(650), R.always(`${'value'} is fair`)],
[R.gte(649), R.always(`${'value'} is poor`)]
])
)