Add flag to Column to sort nulls to the bottom

[TomTirapani]

I'm not 100% sure on the flag name bottomNullSort - suggestions welcome

Apps that implement custom Column.comparators should not need to make any adjustments, as long as they fall back to the provided defaultComparator.

See Toolbox example: xh/toolbox#678

Hoist P/R Checklist

Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

• Caught up with develop branch as of last change.
• Added CHANGELOG entry, or determined not required.
• Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
• Updated doc comments / prop-types, or determined not required.
• Reviewed and tested on Mobile, or determined not required.
• Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

[cnrudd]

maybe bottomNilSort since the check is isNil.

[lbwexler]

Would we want to extend this to NaN, '', undefined? We should consider which other sentinel values (other than zero) might warrant the same treatment? We could even have a list of values, that should be put at the bottom, with the order they should appear there. Would this be useful for values like 'CLOSED'? Or other high-level ordering we want to impose independent of the sorting.

[lbwexler]

could be something like sortToTop:[] sortToBottom:[]

[TomTirapani]

I really like this idea - makes it more flexible and generalizable. We could support an array of values of equality checks, or boolean closures for more complex checks (e.g. v => isNil(v) || itEmpty(v))

[cnrudd]

For values like 'CLOSED', user expectations have been that the 'CLOSED' record be at the bottom no matter which column is sorted, and no matter which column has the 'CLOSED'. So, not sure how useful this would be, unless the comparators allow getting the value from other fields.

[TomTirapani]

Yeah, I don't think we can use this for cross-column sorting like you describe. I think that's kind of an edge case and not necessarily something we should support with hoist out of the box, where the 'normal' use case for sorting is only concerned with the sorted column.

[lbwexler]

Am concerned with the API change on what gets passed to default comparator -- wondering if the "sortToBottom" setting should just translate to a new comparator, or a wrapping comparator around whatever comparator is provided. If the former, a warning could be triggered if you supplied both 'sortToBottom' and comparator and one of them would be ignored.

[lbwexler]

@TomTirapani -- simplified slightly, tweaked performance, and also allowed it to take a single value.

Let me know if it makes sense?

[TomTirapani]

I've updated the PR to use sortToBottom: [], taking an array of values or closures.

[lbwexler]

Every column would probably need this set. Can use defaulting on GridModel for that.

[TomTirapani]

I've updated the PR to move the implementation of sortToBottom to an internal comparator in Column, as discussed yesterday