Add ascendNatural and descendNatural functions

[sebbayer]

There is no built-in way to do natural sorting on strings, therefore I propose ascendNatural and descendNatural to add this functionality via localeCompare. Use exactly like you would with ascend and descend. The implementation is also very similar.

const x = [ '3', '10', 'z', '1', 'a' ]

sort(ascend(identity), x)
> ["1", "10", "3", "a", "z"]

sort(ascendNatural(identity), x)
> ["1", "3", "10", "a", "z"]

[github-actions]

Coverage

> ramda@0.29.1 coverage:summary
> BABEL_ENV=cjs nyc --reporter=text-summary mocha -- --reporter=min --require @babel/register

�[2J�[1;3H
1188 passing (907ms)


=============================== Coverage summary ===============================
Statements   : 94.03% ( 2474/2631 )
Branches     : 85.73% ( 967/1128 )
Functions    : 93.24% ( 552/592 )
Lines        : 94.31% ( 2320/2460 )
================================================================================

[github-actions]

Coverage

> ramda@0.29.1 coverage:summary
> BABEL_ENV=cjs nyc --reporter=text-summary mocha -- --reporter=min --require @babel/register

�[2J�[1;3H
1188 passing (902ms)


=============================== Coverage summary ===============================
Statements   : 94.03% ( 2474/2631 )
Branches     : 85.73% ( 967/1128 )
Functions    : 93.24% ( 552/592 )
Lines        : 94.31% ( 2320/2460 )
================================================================================

[CrossEye]

This seems a useful and well-written PR. These sound like useful additions.

Do others have objections?

[kedashoe]

Feels a bit niche to me? Considering we can write R.sortWith([(a, b) => a.localeCompare(b)], xs). Also the implementation takes away our ability to call localeCompare with our own arguments.. why are we setting { numeric: true } for the options?

[sebbayer]

Thanks for the feedback. Before implementing I was looking up what natural sort order is supposed to do, and by definition in Wikipedia it is

the ordering of strings in alphabetical order, except that multi-digit numbers are treated atomically, i.e., as if they were a single character

So for the most intuitive usage (I thought) I had set { numeric: true } with no locales option set. If users needed different options, there would be sortWith as mentioned. But "alphabetical order" has a different meaning based on language. So for more flexibility, should we be able to pass the locales and options parameters of localeCompare?

[semmel]

Just to revive this proposal, I'd like to add my opinion here too.

Admittedly it's "a bit niche", it fixes sorting text with Ramda. Which is great because <, > comparisons — as ascend and descent perform — do not make sense with text.

If localCompare had been around longer, from the beginning ascend and descent could have used String.localCompare when given String items.

Instead of introducing those two new comparator functions, can you imagine, to change the implementation of ascend and descent for String?

However, the problem is the customization. To sort according to the browser or Node.js locale (language) might be not target-oriented in most cases. I'd suggest to allow to pass at least the language to localCompare.

So that in this case

const
  collectionItemComparator = ascendNatural(identity);
sort(collectionItemComparator('de'), x)

Or should the language come as first argument instead? I.e. is it the least changing argument? sort(ascendNatural('de', identity), x)?

[kedashoe]

Admittedly it's "a bit niche", it fixes sorting text with Ramda. Which is great because <, > comparisons — as ascend and descent perform — do not make sense with text.

Ya and niche was not the right word, ramda could have a better story for sorting by string.

I like language first.

Should this be called localeAscend and localeDescend? Something that immediately implies we are targeting strings here feels appropriate.

@sebbayer sorry for the slow review! Could you add @see references to these new functions from ascend and descend?

[github-actions]

Coverage Summary

> ramda@0.30.0 coverage:summary
> BABEL_ENV=cjs nyc --reporter=text-summary mocha -- --reporter=min --require @babel/register

�[2J�[1;3H
1190 passing (1s)


=============================== Coverage summary ===============================
Statements   : 94.04% ( 2477/2634 )
Branches     : 85.73% ( 967/1128 )
Functions    : 93.25% ( 553/593 )
Lines        : 94.32% ( 2323/2463 )
================================================================================

[sebbayer]

Sorry for the late reply, I am glad there is still interest in the topic.

@semmel I added the language parameter first as you suggested. I hope I got the function signature right.
@kedashoe references in ascend and descend to the new functions have been added.

I updated the functions with better examples and tests have also been updated.

To my surprise the locale based sorting result was pretty much the same in English, German and French, but for example Swedish has differences. My use case so far was only numeric string sorting. I left the { numeric: true } in the code because I think that is how you would expect it to work.

I still like the ascend and descend prefix to the function names. If you look at the list of functions in the documentation, they would come right after the non-natural sorting functions in the list.