As part of our migration of all nextstrain-docs to RTD and docs.nextstrain.org
this commit switches Auspice to using RTD.
There is further work needed in terms of organisation structure, using pages here
under docs.nextstrain.org's RTD page (as opposed to the Auspice subproject), but this
migration paves the way.
No content changes, but lots of syntax changes etc
See https://github.com/nextstrain/docs.nextstrain.org/issues/8 for context.
The leaflet library wasn't pinned correctly resulting in recent
installs of auspice using 1.7.1 which was incompatible with versions
of leaflet-gesture-handling allowed by auspice. See
https://github.com/nextstrain/nextstrain.org/issues/223 for more
information.
This commit fixes the problem by updating both libraries which allows us
to use an improved version of leaflet. The versions are now pinned
exactly preventing this issue in future.
This reverts commit 886e706a3d.
The regex (`const re = /(?<!http[s]?):(?!\/\/)/;`)
was not working on Safari, ER etc and gave the error:
"SyntaxError: Invalid regular expression: invalid group specifier name"
This may be because < looks like a beginning of a named capture group.
In preparation for new nextstrain.org functionality to allow
users to specify custom JSON locations as a URL within the
nextstrain.org URL (see https://github.com/nextstrain/nextstrain.org/pull/216)
we need to improve the logic auspice uses to identify dual trees.
dual trees are defined via <pathA>:<pathB> but we wish to allow a `:` charater
inside pathA (and/or pathB) and not interpret this as requesting two trees.
The narrative to test missing dataset was confusing as the dataset (a "nextstrain community" URL) was invalid for a local auspice server but valid for the nextstrain.org server. Making it a clearly non-existing dataset URL makes it less confusing when testing functionality within nextstrain.org.
This commit represents a big simplification of how we toggle into and out of narrative mode. This happens in two places: the "exit narrative mode" button on the last narrative slide and the "explore the data" button (desktop only). The desired behavior is that we switch to "interactive mode" (i.e. with the controls sidebar) but with a "return to narrative" button (desktop only). The URL should change from a narrative pathname and n=<slide_number> query to the pathname of the dataset & query describing the view settings.
The code is simplified to use a consistent action for all the above behavior ("TOGGLE_NARRATIVE"). This allows multiple datasets to work appropriately, as well as window resizing triggering a switch to mobile display (or vice versa).
This resolves a long-standing development paper-cut where the narrative URL would disappear when hot-reloading (due to the unmounting behavior).
Co-authored-by: eharkins <eli.harkins@gmail.com>
This commit represents a simplification of the page-change logic when navigating between pages (the `EXPERIMENTAL_showMainDisplayMarkdown` action is unnecessary as the `changePage` action will correctly set the panels).
Additionally we rename the react component to remove the "experimental" prefix as this has been in widespread use for a number of months now.
This commit was prompted by a bug resulting from the URL query representing two different concepts: what is displayed in the URL and the app state that this drives.
Previously we approached this with two arguments to the state-setting-function: `query` and `queryToDisplay`. Here we remove the latter and interpret the former as synonymous with the URL. This results in simplified logic where the logic for interpreting what app state a narrative page desires (e.g. `query={n: 3}` -> `{c: "region", ...}) now resides within the `createStateFromQueryOrJSONs` function.
* 1050-mult-narratives: (26 commits)
narrative fetching error handling
Add back in CACHE_JSONS
remove unused action CLEAR_JSON_CACHE
Only clear jsonCache on CLEAN_START;
linting
Update loadData.js
throw 404 when dataset is not available, compatibility fallback for old narratives
async fetching of additional datasets, remove _.uniq
fetch unique set of datasets for narratives
TODOs
fix package lock to same as master
mostly clarifying comments
WIP: remove listeners in components when unmounted
clean up + jsonCache redux sensible default
mult-dataset narratives working;
changing narrative datasets: how to best rerender?
WIP: mult-dataset narratives partly working
WIP allow multiple dataset narratives;
Update recomputeReduxState.js
Update recomputeReduxState.js
...
This commit improves the creation of new state during narrative slide-changes which has a number of beneficial side-effects.
Previously we made a shallow-copy of the (redux) controls state when we changed slides, which resulted in props-comparison of nested state (i.e. objects within the controls state) being hard to reason with. This was problematic with the `temporalConfidence` object, which explains the approach employed in 0713e69b07 to allow narrative slides to update CIs.
We now deep clone the controls state, allowing valid props comparison and allowing us to use this technique to decide when to render / remove CIs. (This is essentially a reversion of 0713e69b07, which was implemented as props comparisons were found to be unreliable).
This commit was motivated by, and fixes#1191. That bug was a result of the previous logic indicating that CIs should be removed on each branch-hover event. This meant that any subsequent tree-manipulation (such as clicking a branch to zoom) would be likely to be considered "in quick succession" to a previous manipulation and thus not employ an animation.
A test narrative is added.
use string.split instead of regex, which
was causing browser to hang (possibly due to
https://www.regular-expressions.info/catastrophic.html)
despite technically valid paragraph missing both the
opening string, "```auspiceMainDisplayMarkdown", and
the closing string, "```".
For unknown reasons, the core-vendors and other-vendors chunks have different hashes when building locally compared with via GitHub CI. This is after running `npm ci` to mimic the CI conditions. An issue should be created to better understand this, as it implies that the contents differ.
The move to client-parsing of narratives has caused two changes to bundle structure.
Firstly, since the `loadJSON` function now references the markdown parsing code, the dependency graph tries to pull in the related libraries into the chunk with most of the Auspice code (currently chunk 5). Previously these were a separate chunk lazily loaded with (e.g.) the footer parsing component. Since it's very common to display markdown footers, it makes life simple to include these libraries in the other-vendors bundle. It is possible to lazily load the markdown parsing function as needed, but more complicated.
Secondly, the YAML frontmatter parser (previously server-side only) has a dependency on `js-yaml` which itself has dependency on "esprima" and others. Esprima is unnecessary for our purposes and we use a webpack loader to ignore it. For simplicity, we shift `js-yaml` to the other-vendors bundle. An alternative approach would be to bundle pre-minified 'js-yaml' bundle.
When running `auspice view` there is some logic to ask if we have a customised client bundle present, which we should serve, or whether we should serve the vanilla (default) auspice client.
PR #1126 introduced hashes into the (client) JS bundle names, which resulted in this logic missing when there was a customised client present, so we would always fall back to the vanilla auspice client.
Parsing of the narrative (YAML) frontmatter produces markdown with `<sup>` and `<sub>` HTML elements to render affiliations using superscripts. (This behavior is unchanged from parsing server-side.) The client-side markdown sanitizer settings, however, were stricter than those employed on the server, and were removing these HTML elements causing the affiliations not to be displayed. These settings are relaxed in this commit.
This commit shifts the parsing of the markdown file (md + yaml frontmatter) into a centralised function which is imported by both the server and the client, allowing us to maintain backward compatible server-side parsing as well as client-side parsing, whilst avoiding code duplication and the inevitable divergence of functionality.
Our approach to conversion of YAML frontmatter -> markdown is essentially unchanged. The algorithm for parsing of the main body has been rewritten to be more robust.
Unit tests are added to cover the various ways we can define authors, links & affiliations in the YAML frontmatter of narratives.
Here we add the framework to (eventually) parse the response from `getNarrative` as a markdown file and interpret this client-side.
To facilitate backward compatibility in the cases where a server does not respect the `?type=md` query and continues to return a JSON, if the file doesn't look like markdown we will attempt to parse it as JSON.
To mimic such a server, we explicitly request "type=json" in this commit, as the code to actually do the client-side md-parsing is not yet implemented.
This is in preparation for client-side parsing of narrative files. A optional `type` URL query allows the same API to return the markdown file (see the documentation changes in this commit for more details).
There are other possibilities, such as using the content-type field in the header, but I felt this was the clearest.
eharkins