Add persistence to API import forms

[rzats]

Closes #62 (but not #63; auth-related fields are omitted here).

• Introduces a new store named formSelections. This is populated when the application is initially launched, and saved in the browser's local storage session storage.
• This stores the user's choices for the currently selected signal, as well as the options for each individual signal.

[melange396]

Instead of enumerating saved fields and setting their defaults for every endpoint component (plus the import dialog component) in src/components/dialogs/formSelections.ts, can we do it piece-by-piece inside each of the individual component definition files? There is already more obfuscation than there needs to be in this app (there is a lot of single-endpoint specific stuff in src/data/data.ts, /src/deriveLinkDefaults.ts and /src/api/EpiData.ts), and having structure and values in a location away from their only usage seems unnecessary. Do we even need all the EndpointFooSelections classes to be defined, or can the components treat the formSelections store as a generic object (where they can create and use their own sub-objects as they please)?

I came across this extension which you might be able to attach to the top-level form or to a <div> that wraps each component to get the persistence for ~free: https://github.com/fawaz-alesayi/svelte-use-persist

[melange396]

simpler:

Suggested change

	export function getFormSelections() {
	try {
	if (sessionStorage.getItem('form')) {
	return JSON.parse(sessionStorage.getItem('form')!) as FormSelections;
	}
	return new FormSelections();
	} catch {
	sessionStorage.removeItem('form');
	return new FormSelections();
	}
	}
	export function getFormSelections() {
	try {
	return JSON.parse(sessionStorage.getItem('form')!) as FormSelections;
	} catch {
	sessionStorage.removeItem('form');
	}
	return new FormSelections();
	}

Also, this seems like it could/should go in src/store.ts since its only ever used there.

[rzats]

I moved this to src/store.ts. However, the if statement should be kept - otherwise it returns JSON.parse(null) on initial load and causes some bad side effects.

[rzats]

Closing this PR - will implement svelte-use-persist in a separate PR instead; this uses sessionStorage internally, so the custom implementation is no longer needed.

[rzats]

And reopening as the svelte-use-persist package does not appear to be functioning well out of the box:

• the base import { persist } from 'svelte-use-persist'; import doesn't work because of some issues in the package's package.json
• even if the code is brought into our environment as a typescript file, the persistent data is lost when the form is reloaded by tabbing in and out of the "import API" menu, even without reloading the page

So let's iterate a bit further on this PR. A couple of notes:

Instead of enumerating saved fields and setting their defaults for every endpoint component (plus the import dialog component) in src/components/dialogs/formSelections.ts, can we do it piece-by-piece inside each of the individual component definition files?

I could add these defaults to the components/dialogs/dataSources/*.svelte files, but the syntax for it is a bit awkward:

// needs to be a separate <script> tag
<script context="module" lang="ts">
  import { cdcLocations } from '../../../data/data';
  export class CdcSelections {
    locations = cdcLocations[0].value;
  }
</script>
<script lang="ts">
  // current code
</script>

This code also compiles and runs fine, but the current parser we use treats it as an error. (This can likely be fixed by modifying the config for it, though.)
Let me know if I should proceed with this approach anyway or if a different one could be used!

Do we even need all the EndpointFooSelections classes to be defined, or can the components treat the formSelections store as a generic object (where they can create and use their own sub-objects as they please)?

TypeScript/Svelte is fairly insistent on defining these sorts of types - I don't believe it's possible to cleanly use a key/value store like formSelections['cdcLocations'] instead of $formSelections.cdc.locations.

[melange396]

I dont love the new formSelections.ts file that defines form default values separate from the forms themselves, but we have some precedent in that the https://github.com/cmu-delphi/www-epivis/blob/dev/src/data/data.ts file already enumerates form-/endpoint-specific choices for locations and dates and etc... What is here will work, though, with a few bits of cleanup!

[melange396]

looks good to me! i think it will be a little tricky merging this with the changes to similar lines in #72... i would probably merge #72 into dev first and then check this one for conflicts before merging it too, but i will let you do them in whichever order youd prefer.