Version sorting

[sgtpepper43]

It would be great to be able to sort version numbers appropriately, right now it just does your standard string comparison so 1.10 is less than 1.9. A complicated solution would be to implement some sort of possibly optional dataType field on that can specify that it's a "version"; a not so complicated solution would be to just use a very basic regex (like /\d+\.\d+/) to determine if the value/column is full of version numbers (or maybe match on if the column header is /version/i?). And then we can just grab node-semver, run coerce on the values and compare them. I'm more than happy to make the PR, just wanna nail down how we'd want to do it first

[andrewjensen]

Thanks for opening this. Intelligent version sorting would be useful for sure.

A couple considerations here:

1. Which version format(s) should we parse and support? If we pull in a library like node-semver that might lock us out of using loose versioning syntax from other communities like Elixir and Ruby, which use their "pessimistic operator" ~> X.Y.Z. So I think I like the idea of pulling out integers and sorting them one level at a time.

2. Should we approach this as a first-class data type, or do we need a concept of custom sorting? Maybe something as domain-specific as a "version" column doesn't belong in the library itself, but should live in the datasite.config.js file instead. Datasite currently generates only static JSON files, so any user-defined code isn't available (today) at runtime. We could either introduce a new concept of generating custom "sorters" and other injected code in the future, which sets us up for having different kinds of visualizations, including custom-built visualizations, in the future. But we're probably not ready to take the plunge and build that out yet. Alternatively, we could store a static "sort score" on each column value in the JSON, which lets us keep the output static for now and should handle custom sorting in user config. This gives us an added benefit of better performance, since sorting is essentially pre-computed for the column.

I think I'm leaning towards implementing this as a generic "sort score" in the library so the user can own their own sorting logic, but I could be persuaded otherwise. What do you think?

[sgtpepper43]

node-semver has a coerce function that can take just about any sort of string and try to turn it into a semver, so it wouldn't really lock us into anything, but then again pulling out the sets of numbers and comparing them one by one would be super quick and easy to write anyway, keeping the bundle size down. But that said, I like the sort score idea. Or maybe just like a sort value? Ah, yeah, I remember now, we did that for teamchat since user's names aren't stored in the database, we fetch them on the fly, so we just store a lowercased version of their full name for sorting purposes. There a bunch of ways for whatever is generating the data to implement it too, like in many cases it would just require coercing the value to some other format, like downcasing strings or parsing dates, and then for versions it probably makes sense to just pre-sort the list and throw on an index.

[andrewjensen]

Perfect, let's plan on adding the ability to sort by a pre-determined value.

Table sorting happens in this function and acts on a DataRow, which currently looks like this:

interface DataRow {
  id: string,
  cells: {
    [columnName: string]: Printable // Problem: we need to include other metadata about each cell!
  }
}

type Printable = string | number | boolean;

// ...

Let's start by defining a new DataCell interface:

interface DataRow {
  id: string,
  cells: {
    [columnName: string]: DataCell
  }
}

interface DataCell {
  value: Printable,
  sortValue?: number
  // I plan to put more properties in here in the future, to support links and other rich content
}

type Printable = string | number | boolean;

// ...

Then sorting can look into each DataCell instance and if it has a sortValue property, we can sort by that.

How does this sound?