orderBy filter has odd results when nulls are compared to Date objects

[hamfastgamgee]

Granted, "odd results" are better than bombing completely, which I think is what used to happen in some cases for orderBy. When you have nulls in the property that is being compared in an orderBy filter and that property is generally a Date (or anything else where .valueOf evaluates to a number but typeof === "object"), the results are effectively unpredictable.

In compare, typeof null evaluates to "object", and typeof also evaluates to "object". Thus, we fall into the t1 === t2 && t1 === "object" block, which calls objectToString() on both values. The null ends up getting converted into a string ("null"), and then the Date ends up getting converted into a number by .valueOf. Back up in compare(), the code goes into the next t1 === t2 block. The values are not equal, so it tries the less than check. "null" < any number always evaluates to false, and so the sort order ends up inconsistent (since the null can be either v1 or v2 depending on the call to compare()). The nulls don't go to either the top or the bottom of the list consistently, regardless of sorting "regular" or "reverse".

I can throw together a plunkr later (too late tonight), but I suspect this is at least enough to get someone thinking. :)

Angular version 1.3.13

[hamfastgamgee]

I strongly suspect the same would be true for, say, Number, but I care about the Date situation, and that's less easy to work around without negative consequences. :)

[hamfastgamgee]

Also, mind you, I'm not sure if there's a general solution to how nulls should sort against all object types or even that whatever gets picked for the default behavior will work for me. I might have to write a custom comparer anyway. But at least the default behavior should probably be well-defined.

[pkozlowski-opensource]

@hamfastgamgee could you please share a plunker with a reproduce scenario? I think that it is already fixed in 1.3.14 or master but a live reproduce scenario would allow us to confirm this.

[hamfastgamgee]

http://embed.plnkr.co/dU2LCUMlqIQ44QgjIdWw/preview

Sorts by default in ascending order, and the header for "The Date" column can be clicked to go to descending order. Where the nulls fall in the list seems to be browser dependent, as I'm getting vastly different results in Firefox and Chrome, neither of which I'd even begin to describe as correct. As I said, "odd". :)

[pkozlowski-opensource]

@hamfastgamgee oh, I see, thnx for the reproduce scenario! Yeh, I agree it is odd, let's do something about it!

[pkozlowski-opensource]

So, look into it a bit more and, funny enough, the current behaviour seems to be "by design". If you see comment in a097aa9 the idea seems to be to keep a comparator's behaviour close to what JS would do. And indeed, as unexpected as it sounds JS will do (at least in Chrome, FFox and Safari):

[null, 'a', null, 'z', null].sort() => ["a", null, null, null, "z"]

So the question here is: do we want to stick to browsers' behaviour or push nulls to the beginning / end? @caitp any particular thoughts on this?