var isDataValid = function( target ) {
return Validation.Success( function( a ) {
return function( b ) {
return target;
}
} )
.ap( isEventAndYearSegmentSelected( target ) )
.ap( isIncomeAccountRelevant( target ) )
.ap( isExpenseAccountRelevant( target ) )
};
@JesterXL more than 3 times at this point, but I'm hoping to publish a series of articles explaining what Purr is, how you program in it, and the development plan 'til the end of this month. I haven't had much time lately to work on things because I'm moving and dealing with immigration stuff and the like has been taking all my time.
The current model is much simpler than the old ones, and it has both gradual types and contracts. As for platforms, the idea is having a stand-alone programming platform with different runtimes you can deploy to without having to rewrite things. Currently Node, Electron, and web runtimes are planned. I want to experiment with a .NET runtime in the future if they release CoreRT, since that lets you ship super small cross-platform native applications. This means that you should be able to write a GUI application and deploy it in the browser, Electron, or as a native app without changing anything in your code.
@jk121960 I think the idea of avoiding if/else in general is misguided. It's the simplest thing that works, and it's the best construct for a lot of problems. You'll see it often in mathematics too (though generally expressed f(a) = b, if c; otherwise d).
There are particular constructs and ideas that, for limited domains, work better than generic branching. For example, the Validation applicative works better for validation than using generic branching—but it's only for validation, you can't really apply that to any other domain. Or the fail-fast approach some monads provide under .chain(), which gives you a sorta railway-oriented programming style.
You can make if/else a function if you want, so you could write: wrap(thing).andThen(f).andThen(choose(isAcceptable, doA, doB)).andThen(moreThingsGoHere), though I particularly think andThen(x => isAcceptable(x) ? doA() : doB()) is clearer and just as concise.
Hello good people, I'm trying the tstypes version of folktale, and was wandering if/how can I import the Task type definition so that I can use it as a return type for some functions of mine.
Things like this:
import {concurrency} from 'folktale';and then trying to use concurrency.task as a typescript type seem to fail... I feel like I'm missing something obvious
@s0kil you can refer to this
@sankemax version 1 is deprecated, and version 2 should be production-ready (with the exception of APIs marked as "experimental", which don't have a particularly solid foundation and haven't been as well-tested as I wish they had been). It's maintained in the sense that I'll still fix bugs if people report them on GitHub (i generally don't get notifications for gitter stuff), but since moving to another country has been a lot more work than predicted I haven't had time to work on any new stuff yet (which means the new version with TypeScript support is still going to take a while to be released)
Do you know what are some other good libraries similar to Folktale and stable or that implement only the union types that I can combine with folktale ? thanks
task and it's great, but I'm wondering how to adapt a pattern I have been using with the old-style Task.For rejections, I would use daggy to enumerate different kinds of failures with a sum type, and then handle them in the rejection handler of the
.fork(reject, success) call
Errors thrown to .catch() right?
.orElse(rejectionsHandler).run().promise().catch(handleUnforseenErrors)
@borodinalive maybe use a kind of a thin broker like
// _unstableFilterMaybe.js
export default pred => m => m.filter(pred)
// your code
import _filterMaybe from '_unstableFilterMaybe.js'
_filterMaybe( x => !!x)(someMaybe)At least this way, even if you used the experimental filter and if one day it changed implementation, you only have one file, namely _unstableFilterMaybe.js, to change to accommodate your own code.
Hi, new(ish) user of Folktale, its great thanks!
I have a, probably basic, problem which I cannot figure out. I have two Task objects, each of which will resolve to an array, e.g.:
const t1 = Task.of([49]);
const t2 = Task.of(['john', 'paul']); // In reality, these tasks are being created from promises which are fetching dataI want to merge the arrays such that I get each unique combination, e.g. if I had just arrays I might do:
a1.map(resourceId => a2.map(name => ({ name, resourceId }))) // [{ name: 'john', resourceId : 49}, { name: 'paul', resourceId: 49}]I can't figure out the best way to do this from Tasks - any help appreciated!
@JamesRamm Hi James, I think you can do that through something called list comprehension. So I am using a library that does List monoid immutable-ext to achieve the result:
import { task, of, waitAll } from 'folktale/concurrency/task';
import { List } from 'immutable-ext';
const ids = of([49, 51])
const names = of(['joh', 'paul', 'francis'])
const comprehend = id => name => ({id, name})
let res = {};
waitAll([ids, names])
.run()
.listen({onResolved: ([ids, names]) =>
{
res = {value: List.of(comprehend).ap(List(ids)).ap(List(names)).toArray()}
}
})Here's the link to the code sandbox https://codesandbox.io/s/competent-river-mqx2u?file=/src/App.tsx
{
"value": [
{
"id": 49,
"name": "joh"
},
{
"id": 49,
"name": "paul"
},
{
"id": 49,
"name": "francis"
},
{
"id": 51,
"name": "joh"
},
{
"id": 51,
"name": "paul"
},
{
"id": 51,
"name": "francis"
}
]
}