feat: homepage sunburst display of available data (#289)

[dannon]

This provides the main visualization component for resolving #289. Separated color scheme options/discussion out per discussion on the call, which will be another PR.

There are several follow-ups to pursue but this is in a shape we can merge and move forward, with comments addressed.

[hunterckx]

I am told that this is about ready for review, so here are some potential issues I notice currently:

• The mapping from rank to filter key still includes superkingdom, which should be replaced with domain and realm.
• strain is also absent from the mapping, despite appearing in the tree.
• It seems odd to me that the filter defaults to genus when the rank isn't in the mapping -- I would expect createFilterUrl to return null in that case maybe?
• The leaf node counts that are labeled as "assemblies" in the interface don't really correspond to anything in the data browser (meaning the result count doesn't match when you open the link to the filtered assemblies) -- the assembly list in the data browser has multiple assemblies for some taxa, and the organisms list wouldn't fit either because it's a list of species (as opposed to potentially being more granular with strain/etc like the tree is).
  • I'm not sure what the best immediate solution would be, but something I've talked about with @NoopDog that I'm not sure ever got brought up elsewhere is that we could build the taxa tree from the taxonomic data that we were already using in the assembly list; if we did that it would likely be straightforward to count the assemblies as the tree is built.

Regarding the type errors in sunburst.tsx, I think there are three broad categories of errors that I see (although note that my impressions are based in large part on the type definitions for d3 so it's possible I'm missing some subtleties):

• Lack of type annotations, both for parameters in function definitions and as type parameters to function calls; e.g.:
  • On line 42, getNodeColor lacks type annotations for its parameters, which causes them to default to any and is disallowed by our configuration; the d3 types suggest that the parameters should be typed as d: d3.HierarchyRectangularNode<SourceTreeNode>, root: d3.HierarchyRectangularNode<SourceTreeNode>, if the TreeNode type from data.ts was imported as SourceTreeNode.
  • On line 107, d3.partition() takes a type parameter that defaults to unknown, which causes a mismatch when hierarchyData is passed in later. The d3 types suggest that that initial function call should be d3.partition<SourceTreeNode>().
• Inaccurate type annotations? It seems to me like there might be some confusion between the TreeNode type from data.ts, the TreeNode type from NodeDetails.tsx, and the d3 node types -- though looking more closely maybe TreeNode from NodeDetails is intentionally used for d3 nodes? (In which case I might expect it to be defined by extending a d3 type if possible.)
• The addition of properties such as current to d3 nodes (assuming I'm understanding correctly and that's what's going on?) -- I think it would work better with TypeScript if that data could be stored outside the d3 node (such as via a map and/or the data associated with the node), but if that's not feasible a solution might be to define something like getCurrent and setCurrent functions that use type assertions to allow the current property to be referenced. Or, if the TreeNode type represents the addition of these properties, maybe just inline as TreeNode would be appropriate?

[mvdbeek]

Awesome, works well @dannon!