New dataset selector

[jameshadfield]

Review app for nextstrain.org
Review app for stand-alone Auspice

The sidebar-based dataset selector has existed unchanged for many years
now, despite many nextstrain.org changes to how datasets are served
(different sources, snapshots etc).

This commit completely redesigns the selector UI, whilst still
leveraging the same underlying data (via the charon/getAvailable API
call). The two big UI improvements are to allow multiple changes to
different parts of the heirarcy (rather than changing page as soon as
anything was changed), and to allow snapshots to be requested.

A number of bugs are fixed, namely those which occured when changing an
intermediate-level option wouldn't preserve deeper options.² For
instance, previously viewing "seasonal-flu/h3n2/na/3y" then changing
"na" to "ha" would change "3y" to "2y"¹. The UI now preserves the
choices for different levels where possible, and selects defaults where
necessary.³

As with a redesign like this there are future avenues to persue if we
choose to!

• There is a conflict between Auspice-specific code and nextstrain.org
  specific code, especially for snapshots.
• Snapshots aren't available in the (nextstrain.org) getAvailable API
  response, so we allow any YYYY-MM-DD value and rely on the server to
  handle these appropriately.
• The nextstrain.org getAvailable data is per-source, e.g. for core
  datasets you can only see other core datasets. We could greatly
  rethink this, but this is better done as a redesign of the
  getAvailable API.
• Expose available narratives via the UI. I started out intending to do
  this but didn't get round to it.

Closes #560
Closes #697
Closes nextstrain/nextstrain.org#352
Closes nextstrain/nextstrain.org#40

¹ This happened because the client made a request to
seasonal-flu/h3n2/ha which was expanded to the canonical/default 2y
timespan

² This resulted in bugs when the server didn't redirect, most common
on nextstrain.org groups and community pages, e.g. see
nextstrain/nextstrain.org#40

³ If a level's chosen option isn't available (e.g. change 'seasonal-flu'
to 'avian-flu' and thus 'h3n2' doesn't exist) then we choose a default
by looking at the first applicable option from the available datasets.
This doesn't necesarily match the default on the server-side, which is
set via the manifest JSON. In the avian-flu case, the UI will select
'h5n1-cattle-outbreak' but the server would have selected 'h5n1'.

---

Original PR message (now outdated)

As part of diving into the quirks of how we change datasets yesterday I ended up prototyping how a new auspice selector might work. Early days, but I think this has promise. The main idea is that we leverage the getAvailable data API to limit Auspice into only allowing valid selections, so there should never be a situation where the server has to canonicalize / redirect the requested dataset.

@victorlin @joverlee521 I'd be interested in your thoughts at this early stage

E.g. load https://nextstrain-s-nextstrain-amsecf.herokuapp.com/groups/blab/229e/E, click on the dataset (top of sidebar), and interact with the new modal.

[victorlin]

Nice! I found this nested example useful for exploring more: https://nextstrain-s-nextstrain-amsecf.herokuapp.com/groups/blab/flu/seasonal/h1n1pdm/ha/12y

Haven't looked at the code, but looks great in terms of functionality. Not sure if you want feedback on UI at this stage, so I'll hold back on that.

[joverlee521]

Nice, I really like this direction! In brief testing, this works with core, groups (within single group), and community (within single repo). Doesn't work as well with staging but that seems expected since the available datasets for staging is just a duplication of core.

I'm all for pushing on this to polish the UI and getting this out!

[jameshadfield]

I'm all for pushing on this to polish the UI and getting this out!

Great - seems like there's consensus here. I think the behaviour is pretty good, although I still want to:

• look into the relationship between the core getAvailable data and our concepts of defaults
• work out if we ever have or want "partial" datasets, e.g. A + A/B, as that complicates things a fair bit
• make versioned @YYYY-MM-DD datasets work
• think about 2-tree views

Doesn't work as well with staging but that seems expected since the available datasets for staging is just a duplication of core.

Good observation. I think that should be improved, but on the server-side as you imply. The simplest would be akin to what we do for groups (basically run aws s3 ls every ~hour) or leverage the resource indexer (which we're already using), but I'm going to stay away for now...

Haven't looked at the code, but looks great in terms of functionality. Not sure if you want feedback on UI at this stage, so I'll hold back on that.

Please share any big UI ideas you have! I was thinking of adding buttons/tabs for "datasets" vs "narratives", but otherwise just polishing what you see here.

[joverlee521]

Left mostly minor comments and notes on odd behaviors I noticed. Overall, like I said before, I really like this new design!

[joverlee521]

Not asking for change, just want to document behavior that I've seen

Really awesome that this works for snapshots of the core datasets in nextstrain.org! I wish we could hide it for groups/community which don't support the snapshots. From a groups/community dataset, entering a snapshot will go to an error page, which I think is ~fine.

As you noted this is not ideal in vanilla Auspice: if I enter a snapshot that does not exist as part of the filename, then the dataset goes to the default (?) dataset instead of an error page.

Screen.Recording.2026-01-09.at.2.55.50.PM.mov

[jameshadfield]

This encouraged me to actually sort it out rather than the unsatisfying place I had left it at.

I modified the getAvailable response structure to allow datasets to specify an optional snapshosts boolean (undocumented at the moment), and only when a dataset supports it does the UI allow snapshots to be entered. This requires a small nextstrain.org server change to expose the snapshots UI for core/nextclade datasets.

P.S. I left it undocumented as we might want to change from a boolean to a list of known snapshots in the future, but I don't want to block on that possible enhancement.