Update preference management

[allison-truhlar]

@krokicki @neomorphic
This PR is now ready for review. I can wait to fully merge it until I integrate the build changes from Jody.

The main change is adding the construction of the "uber map" in FileBrowserContext.tsx and updating the preference management to store hash keys. The format for these keys is the same as in the "uber map" for zones (zone_{fsp.zone}) and FSPs (fsp_{fsp.name}). The folder preference key format is folder_{fsp.name}_{folder.path}. In addition to being used to access zones and fsps for the favorites, the "uber map" is now also used for populating the ZoneBrowser.

I also updated some types/types names in shared.types.ts, most notably File to FileOrFolder, since that's a more accurate description and also avoids the error that would sometimes occur if I forgot to import the File type, and the built-in JS interface File would be assigned as the type.

[github-actions]

👈 Launch a Binder on branch JaneliaSciComp/fileglancer/update-preference-management

[krokicki]

Great start! Some of my thoughts below.

[allison-truhlar]

@krokicki Do the PreferencesContext look on the right track? See commit fafb0a8

[krokicki]

@krokicki Do the PreferencesContext look on the right track? See commit fafb0a8

Much improved! I can't build this PR right now though, there is some kind of build error.

[allison-truhlar]

@krokicki The zone favorites should now be working on this branch. I decided to move forward with saving the zone favorite data in the same format at the Zone type used in the "uber" map, as opposed to the format we previously discussed: {type: zone, name: fsp.name}. The reason being I thought this would reduce the number of different states to keep track of. If we used the favorite-specific format, then I thought I would need to save these abbreviated data in a separate state to check whether a specific entry exists when updating the favorites, as well as separate state that stores the zones (or FSPs or folders) that gets passed to the components to render the favorites. Does this seem right to you? Is there any downside to saving the whole zone (or FSP) object to preferences, rather than just the abbreviated format?

[krokicki]

Hi @allison-truhlar,

The reason for the expanded format was to make it easier to reconstitute the data. If you only have the key then you have to parse it (i.e. split on underscores). It will work to use the keys, but it introduces fragility and certain limitations. For example, it prevents the use of underscores in the values moving forward.

By the way, I was able to build the branch, but I can't see the file share paths. They seem to load fine in the console, and the zones are displayed, but it seems like they're all empty:

Also, it's still saving the entire object as a preference. The idea was to save as little information as possible, to avoid having data in multiple places that can be desynced, and also for efficiency.

Here, the preference should just be either {value: ["zone_Abbot", "zone_Beyene"]} or {value: [{type:"zone", name:"Abbot"},{type:"zone","Beyene"}]}. The rest of the information can be reconstituted when loading the preferences.

[krokicki]

Not sure if it was the merge, but there are several things broken. I fixed one syntax issue, but there are a few in FavoritesBrowser that I can't resolve (it uses the type FolderFavorite which is not defined anywhere).

These issues are being caught if you run npm run eslint:check but for some reason we're not running that in the CI. We should probably enable that and prettier and make a habit of using both before pushing code (or even add a precommit).