-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidation behavior #18
Comments
The polyfill v0.3.0 keeps the first equal element, as what proposal-array-unique/polyfill/index.ts Line 28 in 0df27fa
|
It seems most userland libs keep first. There are use cases which prefer last. For example, dedup update operations and use the last update. But in such cases, we possible need much more control, for example, in https://stackoverflow.com/questions/27234820/how-to-make-javascript-array-unique-by-attribute the author want keep the item with biggest timestamp. A possible solution is allow second param: data.uniqueBy(v => v.release, (x, y) => y.timestamp > x.timestamp) |
Can you post your full findings? |
Both lodash, ramda keep first. I also found another two packages in npm (but forgot accurate names now, need to search again) also keep first. Note, I guess ramda just copied lodash behavior, so other packages may also just copied lodash. |
I don't believe the essence of unique is to provide configurability of how to pick values that are unique. To that end a developer can lean on filter and reduce to assure controlling selection. Just like we've seen from previous libraries that have stemmed from lodash, this is probably a justifiably separate concern. |
The following is my "2 cents" of personal experience: There are some cases where keeping the last occurrence is desirable. This is an example in Python Anything that is a "history" or "log" can benefit from removing old duplicates. Old dupes are usually located at the beginning of a list/array (unless the format is reversed). Therefore I conclude that keeping the last item may prove to be useful in practice |
Should the unique operation keep the first value with a given surrogate key or the last, and at what index? Is there reason to make it author-configurable?
The text was updated successfully, but these errors were encountered: