all applies a single predicate to a list of values.
const hasRequiredKeys = R.allPass(R.map(R.has, required_keys))and hen just do hasRequiredKeys(obj)
reduce of ramda only passes accumulator and next value, not index of the element processed. So you also need addIndex to get a reduce function that passes both index and value
26 replies
import { compose, fromPairs, map, props } from "ramda";
type Category = {
id: number;
name: string;
};
const data: Category[] = [
{
id: 1,
name: "foo"
},
{
id: 2,
name: "bar"
}
];
const idNames = compose(
fromPairs,
map(props(["id", "name"]))
);
const obj = idNames(data);
console.log("obj", obj);Argument of type 'unknown[]' is not assignable to parameter of type '(x0: unknown, x1: unknown, x2: unknown) => KeyValuePair<number, unknown>[]'.
Type 'unknown[]' provides no match for the signature '(x0: unknown, x1: unknown, x2: unknown): KeyValuePair<number, unknown>[]'.
21 map(props(["id", "name"]))
pipebut I missing something there. someone can help, please.
example:
https://ramdajs.com/repl/?v=0.27.0#?%0Aconst%20publicationlist%20%3D%20%5B%0A%20%20%7B%0A%20%20%20%20id%3A%20%271%27%2C%0A%20%20%20%20provider%3A%20%27A%27%2C%0A%20%20%7D%2C%0A%20%20%20%20%7B%0A%20%20%20%20id%3A%20%272%27%2C%0A%20%20%20%20provider%3A%20%27B%27%2C%0A%20%20%7D%2C%0A%20%20%20%20%7B%0A%20%20%20%20id%3A%20%273%27%2C%0A%20%20%20%20provider%3A%20%27C%27%2C%0A%20%20%7D%2C%0A%20%20%20%20%7B%0A%20%20%20%20id%3A%20%274%27%2C%0A%20%20%20%20provider%3A%20%27A%27%2C%0A%20%20%7D%2C%0A%20%20%20%20%7B%0A%20%20%20%20id%3A%20%275%27%2C%0A%20%20%20%20provider%3A%20%27A%27%2C%0A%20%20%7D%2C%0A%5D%20%0A%0Aconst%20filterByProvider%20%3D%20R.curry%28%28providerList%2C%20publications%29%20%3D%3E%0A%20%20R.filter%28item%20%3D%3E%20%28providerList.length%20%3E%200%29%20%3F%20providerList.includes%28item.provider%29%20%3A%20true%20%2C%20publications%29%29%0A%0Aconst%20filterById%20%3D%20R.curry%28%28idList%2C%20publications%29%20%3D%3E%0A%20%20R.filter%28item%20%3D%3E%20%28idList.length%20%3E%200%29%20%3F%20idList.includes%28item.id%29%20%3A%20true%20%2C%20publications%29%29%0A%0A%0Aconst%20x%20%3D%20%28providerList%2C%20idList%2C%20publications%29%20%3D%3E%20R.pipe%28%0A%20%20filterByProvider%28providerList%2C%20publications%29%2C%0A%20%20filterById%28idList%2C%20publications%29%0A%29%0A%0Aconst%20result%20%3D%20x%28%5B%27A%27%2C%20%27B%27%5D%2C%20%5B%273%27%5D%2C%20publicationlist%29%0A%0Aconsole.log%28result%2C%20%27result%27%29%0A%0A%0A%0A%0A%0A%0A%0A
https://codepen.io/adispring/pen/BazGNdE?editors=0010 .
R.pipe should compose small functions into a bigger function. In your code, R.pipe composes functions' results, which results in the wrong behavior.
R.pipeWith do the same thing in the reverse way. There is an example in ramda's document: https://ramdajs.com/docs/#composeWith. composeWhileNotNil could process data continuously while the data is not nil, otherwise, it will return undefined/null in the shortcut way.
ap are slightly inaccurate, as they state that it will dispatch to the .ap method of the 2nd argument, whereas in reality it dispatches to the .ap method of the first argument (which makes more sense to me anyway)
fantasy-land/ap method of the second argument, though, which might be what the docs mean
I'm new to TS, and don't find it especially friendly to my unary functions... does anyone have some input on this?
snapshot wrong, or if you really have to so verbose as to take all the arguments and pass them through just to type them.const tag = snapshot (x => _ => x)
// vs
const tag = <X, Y> (boxX: Box<X>) => (boxY: Box<Y>) => snapshot ((x: X) => _ => x) (boxX) (boxY)const tag = snapshot (<X> (x: X) => _ => x)
Newbie here! Wondering how I would apply fp along with error handling. There is this notion of Railway Oriented Programming, but it does seem like there is a need to have some monads (Maybe and Join??) that are not available on Rambda and I should look into Santuary to really leverage Railway Oriented. Here's my question:
const hasNoCitationNumber = citation => R.isNil(R.prop('citationNumber', citation))
const citationValidation = citation => {
if (hasNoCitationNumber(citation)) {
throw new TypeError('Citation number is required')
}
return citation
}
const calculateAmount = citation => {
const balance = R.add(R.prop('amount', citation), R.prop('fee', citation))
return {
...citation,
balance
}
}
const citationService = R.pipe(citationValidation, calculateAmount)
const citation = {citationNumber: '12345', amount: 100, fee: 10}
//citationService(citation)
const pipeWhileNotError = R.pipeWith((f, res) => R.is(TypeError) ? res : f(res))
const citationBuilder = pipeWhileNotError([citationValidation, calculateAmount])
//citationBuilder(citation)
citationBuilder({})is this right? Is this truly error handling in fp?
citationValidation we could question the fact of it returning an Object or an Error (Object | Error) and it is not explicit in the function signature since javascript has not types. If you would like to be very fp purist, maybe you could encapsulate the return value in a Either like monad.
const citationValidation = citation => {
if (hasNoCitationNumber(citation)) {
throw new TypeError('Citation number is required')
}
return citation
}We should separate out the specific validation we are doing from the way that we are validating. In this case, the specific validation is hasNoCitationNumber, and citationValidation just wraps that.
The way you are validating in this case is by throwing an error. Let's pull that out:
const validate = curry((predicate, message, object) => {
if (!predicate(object)) {
throw new TypeError(message);
}
return object;
}
const citationValidation = validate(hasNoCitationNumber, 'Citation number is required');Now we can easily construct new validators that will do the same thing as our existing one. We can also swap out the error handling (for instance to use Either):
const validate = curry((predicate, message, object) => predicate(object) ? Right(object) : Left(message));All the rest of the code can stay the same.
pipeWith. It will still short circuit the rest of the pipe, but I think you'd want to return the error in citationValidation instead of throwing it...
Would not it just be the version scheme that Ramda follows? Not being above 0 in the version schemes does not necessarily means that a lib is dying, I hope.
Not dying, but we really need to get on a more consistent release schedule. We're working on that!
Ramda doesn't have those and probably won't have them in the future. It's more focused on utilities that work with typical JS entities, and it dispatches so that you can use custom objects.
A lot of Ramda users also use Sanctuary, however it's a lot more strict as it has a runtime type checker. You can use the data types without the type checking by either turning type checking off or else importing the individual projects (i.e. sanctuary-either). There are a few other projects out there I have used for the data types that I like: Crocks has a lot of good ADTs and utilities. I used to use Folktale but a while ago they did a huge update and I lost track of the project after that.