setIsOpen = (open) => this.isOpen = true
is there a way to wrap it so it ends up being setIsOpen = (open) => () => this.isOpen = true
?
flowRight(
toArray
map(myMapFunc)
)(myMap)
pipe
function
pipe
over compose
?
flowRight(
x => x.toArray(),
x => x.map(myMapFunc)
)(myMap)
flatten
method, and flatMap, flatMapConcat
, and others need a second streamBacon.fromPoll(x, () => Bacon.fromPromise(returnPromise()))
R.unnest
should do the trick (if Bacon is compatible with old versions of Fantasy Land).
flatMap(x => x)
try it
R.unnest
the highest level of R.unny
and R.unner
? ;)
flowRight(
invoker(0, 'toArray'),
invoker(1, 'map')(myMapFunc)
)(myMap)
arguably less readable for this particular example, but good for defining reusable functions
TLDR: What is unit testing like with Futures and chaining? Do you have any examples of unit tests covering things like that? Do you even bother with it?
I’m not sure if this is an appropriate place to ask this question, so forgive me if that’s the case. Right now my team is experimenting with utilizing a more functional approach to software development. We all come from a TDD background with all kinds of mock and stubbing experience. We also don’t like the mocks so much :)
Our general architecture is moving toward composition at the outer edges of the system and then pushing branching logic into pure functions (except IO currently). We’re mostly on board with not testing those compose functions at the unit level, but rather just using integration or acceptance tests. But the thing that is causing some worry is general omitted code where we can’t determine correctness through outside behavior alone. Here’s an example:
getData(dataIds) {
return getDataFromCache(dataIds)
//.then(filterExpiredData) //Whoops, we should be calling this.
.then(getMissingDataFromApi)
}
My question is, will taking the next step into things like futures and chaining them together help our testing situation? Will we be able to test our compositions without mocks? Or would we still not test compositions at the unit level?
Any insight would be greatly appreciated.
done
argument is like testing a promise
import identity from 'ramda/src/identity'
import partial from 'ramda/src/partial'
import compose from 'ramda/src/compose'
import tap from 'ramda/src/tap'
const FAIL_MSG = chalk.bold.red('Test Executed Unreachable Code')
/**
* Create a function to use as contingency for unreachable code
* in an asynchronous test.
*
* @param doneCallback
* @return {*}
*/
export default function unreachableTestCode(doneCallback, verbose = 0) {
return compose(
partial(
doneCallback,
[new Error(FAIL_MSG)]
),
!verbose ? identity : tap(
console.log.bind(console,
`\n${ chalk.bold.underline('TEST STDOUT') + chalk.bold(' >> ') }\n`)
)
)
}
import unreachable from '../helpers/unreachableTestCode'
it('testing of a future', function (done) {
someFutureReturingFn.fork(
unreachable(done/* optional boolean argument to logout error */),
(resolvedVal) => {
/* some tests go here */
done()
}
)
})
chai-fetch
with API calls, so then I use a composition that contains an API call in a test, but I'm not really testing the composition as much as testing the side-effect, does it call the correct url, does it call it with the correct properties. I'm not a testing guru or anything, but it seems to work and with chai fetch there's no bloat in the code. I'll send you a snippet in a PM
R.invoker
if you wanted to. maxBy(invoker(0, 'valueOf'))
maxBy(x => x.valueOf())
npm i -g babel-cli
)