rambdax
rambdax copied to clipboard
selfrefactor
Suggestion for new methods
This issue will be kept open to keep track of various suggestion for new Rambdax methods
Often, the only reason I still have to use Ramda is because of R.chain. Array.flatMap is not 100%-replacement (and not pipe-able). Not sure why it was not included in Rambdax.
@cjk Good suggestion. I will get back to you when I have a proposal for method's specification.
also by removing R.addIndex , I can't find any way to get index of current element when using R.find. I don't want to use R.indexOf in the callback of iteration.
@8bu I see your valid point - I will restore R.addIndex but I may need 2 more weeks for that as I am in the middle of building the next version and I still have some things to complete.
I created separate issue for your suggestion - https://github.com/selfrefactor/rambdax/issues/51 and thank you for your input.
@8bu I see your valid point - I will restore
R.addIndexbut I may need 2 more weeks for that as I am in the middle of building the next version and I still have some things to complete.I created separate issue for your suggestion - #51 and thank you for your input.
I just discussed with my friend, he said your R.find has added index as 2nd arg like R.findIndex but the docs hasn't updated yet. I did double check, R.find do have index as 2nd arg. But type & document haven't updated it.
=>> So Typescript won't allow me to use 2nd arg if the type haven't updated. I will make a PR to update typescript type for those functions. For the docs I will leave it to you.
wonderful, but you have to keep in mind that the PR should be for Rambda repo, not Rambdax, as not this repo serves only as output, while Rambda holds all the tests and the source of the methods. Still, if it is easier for you to create the PR for Rambdax, then please do so, I will make sure that your changes are applied correctly and the final result is as expected.
@8bu I will close the issue for restore of R.addIndex and I will try to fix the typings of R.find to allow you to use the index argument.
@8bu I will close the issue for restore of
R.addIndexand I will try to fix the typings ofR.findto allow you to use the index argument.
Sorry I've been busy with works this month. I did submit a PR for the type problem but it's in this repo, so I close that already. You can take a look at that PR
I saw the PR in question and I will try to implement its logic. I will keep you informed on the progress.
I started implementing your suggestions. One thing to share is that R.adjust doesn't pass index to the function argument, as it doesn't iterate over the list.
As for the rest of the changes - I just applied them to Rambda repo and will be published with the upcoming 5.9.0.
In Rambdax these changes will come with the upcoming 4.0.0 which should be ready in 2 weeks time.
@cjk R.chain is added in Rambda and will be added to Rambdax with version 4.0.0.
https://github.com/selfrefactor/rambda#chain
@selfrefactor Fantastic news - that finally enables me to ship one less library with my various apps. Thanks a lot!
@selfrefactor Do you still want requests in this issue, or somewhere else? I recently tried to switch to Rambdax and found I was missing juxt, unary, invoker, and a few others. I could get the longer list if you're interested.
@agriffis Yes, I am still interested in adding more methods, so please share more of this list of missing methods.
Here's the full list:
R.__
R.addIndex
R.construct
R.countBy
R.dissocPath
R.invoker
R.juxt
R.mergeRight
R.nthArg
R.pickBy
R.reduced
R.sortWith
R.unary
R.uniqBy
R.unnest
This is the result of grepping my project and then uniq -d with the list of missing methods from your README.
I didn't attempt to go through this and make sense of it yet. There might be some methods here that would be better handled by separate methods on Rambdax. For example addIndex isn't really that interesting in Rambdax. However unary becomes more interesting when passing to Rambdax map to avoid the extra function parameters when they're problematic (for example, parseInt)
I'm particularly fond of reduced. I wrote an implementation of it once that might apply:
class Reduced<T> extends Error {
value: T
constructor(value: T) {
super()
this.value = value
}
}
const reduced = <T>(x: T) => new Reduced(x)
interface Reducer {
<T, K>(items: T[], fn: (acc: K, item: T) => K | Reduced<K>, initial: K): K
indexed: <T, K>(
items: T[],
fn: (acc: K, item: T, index: number, items: T[]) => K | Reduced<K>,
initial: K,
) => K
}
const reduce: Reducer = (items, fn, initial) => {
try {
return R.reduce(
items,
(...args) => {
const r = fn(...args)
if (r instanceof Reduced) {
throw r
}
return r
},
initial,
)
} catch (e) {
if (e instanceof Reduced) {
return e.value
}
throw e
}
}