Made audio, scalar, graph demo work again

[stephanwlee]

Major changes:

1. All demo fixtures have proper file extension defined
2. Because of 1, router has changed significantly to embed the demo url generation logic with appropriate file extensions

Minor changes are:
a. audio_dashboard had missing </template> only causing demo to not work
b. graph_dashboard was missing an import statement for tf_storage

[nfelt]

This appears to be unused?

[nfelt]

Given that this is new functionality, it seems better to me to just require passing in an actual URLSearchParams object, rather than sticking with the custom QueryParams type. You can construct URLSearchParams directly from a map, so most callsites can be updated by just wrapping a new URLSearchParams() around the argument. I don't actually know that we have any callsites that use repeated/list-valued parameters, but if so, they can pass in a list of pairs instead or build up the instance via append().

This way the code in e.g. the audio plugin can be much simpler since there's no need to create URLSearchParams, convert it into QueryParams, and then reconvert back.

[nfelt]

typo: s/correcrt/correct/ here and below

[nfelt]

The extension is already ignored unless we're in demo mode, so simpler to just pass '.wav' all the time and let Router figure it out.

[stephanwlee]

Ugh, it looks like, although you can pass object to the constructor of URLSearchParams and get the right instance, it is defined to take string or another instance of URLSearchParams (https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#Parameters). Either that or someone is not updated correctly and TypeScript disallows passing a object :(

[wchargin]

@stephanwlee: This appears to break the --path_prefix functionality?

Before this commit, running

bazel run //tensorboard -- --logdir ~/tensorboard_data/ --path_prefix /test/

and then navigating to http://localhost:6006/test/ yielded a fully
functioning TensorBoard instance (albeit with broken webfonts). After
this commit, it fails to load the set of active dashboards.

Network traffic indicates that the frontend is hitting /data/...
instead of /test/data/... as it did before this commit.

Git bisect says:

05b22e8 is the first bad commit

Could you please investigate?

[wchargin]

From what I can tell, it looked like the result of the default router’s
pluginsListing() method changed in this commit:

• old: data/plugins_listing;
• new: /data/plugins_listing.

The --path_prefix argument never propagated explicitly into the
router; it’s just that we were previously fetching relative paths so
everything worked out, but as of this commit that is no longer the case.