Store slot visibility settings on a per-Study basis

[pkalita-lbl]

Fixes #150

Summary

Currently, slot visibility is stored as an app-level setting. This means that, for a given user, all studies that use the soil template (for example) will show the same set of slots. But two users with access to the same study may see different slots depending on their app settings. During beta testing we received feedback that:

• Users found it confusing that they weren't asked to customize the slot visibility on a per-study basis
• Users wondered how they might share the slot visibility settings with others who have access to the same study

To address those pain points, these changes update slot visibility so that it is a property of a study (technically a SubmissionMetadata record), as opposed to a local app setting. The supporting backend changes have already been merged into nmdc-server in microbiomedata/nmdc-server#1473.

These changes also address the feedback that choosing from a long list of slots associated with a given template can be overwhelming. The solution here is to use the results of some manual curation of slots by team members to group and prioritize slots that are often collected at sampling time (and thus while using the app) versus slots that might be collected at sampling time vs all other slots.

Details

• In src/Store.tsx, functions for setting and getting slot visibility state have been removed since that information will no longer be stored there.
• The dedicated settings page for slot visibility (src/pages/FieldVisibilitySettingsPage/FieldVisibilitySettingsPage.tsx) has been removed, along with the routing and links to the that page (src/Router.tsx, src/components/SettingsAppearanceList/SettingsAppearanceList.tsx, src/paths.ts)
• The StudyView component (src/components/StudyView/StudyView.tsx) now explicitly lists which template was selected for the study, along with the number of visible slots chosen. The StudyView is also now responsible for presenting the SlotSelectorModal component when tapping on the template name. This design decision has an eye toward the fact that more than one template will be allowed in the near future. Previously, the SlotSelectorModal was presented by the SampleView component. Since the visible slots are now managed at the study level, this list of slots is passed to SlotSelectorModal by StudyView.
• After creating a new study, we want the user to immediately be presented the slot visibility selector modal for the newly created study. The idea is to make this feel to the user like a "second step" in the study creation process (even though technically the study is already created at that point). This is accomplished by using a bit of routing state, managed by two new hooks. useNavigateWithState exposes a navigate function which uses a history object to navigate to a new route with state. Then useNavigationState is used to access and optionally clear that state. The StudyCreatePage component uses useNavigateWithState to navigate to the newly created study page with a openSlotSelectorModalOnEnter flag set. Then the StudyViewPage component uses useNavigationState to get that flag and pass it along to the StudyView component. The flag is also cleared after it is used so that navigating away from the StudyViewPage and then back to it does not re-trigger the slot selector modal.
• Slot grouping and sorting functions (groupTemplateSlots in src/components/SlotSelectorModal/SlotSelectorModal.tsx and sortSlots in src/utils.ts) and their usage have been updated to reflect that we are not using the grouping and sorting indicated by the submission schema itself anymore, which was designed for the Submission Portal. Instead, we are using a more simplified grouping and sorting that is more user-friendly for the Field Notes app. The file src/components/SlotSelectorModal/slotVisibilities.ts was created as a result of a manual assessment of slots by NMDC team members and is used to drive the new grouping logic.
• Minor tangential changes:
  • A new set of custom CSS variables (--nmdc-font-size-*) have been added in order to standardize font sizes. These are also wrapped in new utility CSS classes (.nmdc-text-* in src/theme/global.css)
  • TypeScript types of variables that are supposed to be template names (i.e. a key of the TEMPLATES object in src/api.ts -- as opposed to an arbitrary string) have been tighten up.

[pkalita-lbl]

This is open for review now even though it is still a draft.

I'm leaving it as a draft as a reminder to myself to not merge it yet. I want to first merge #205, then put out a new build to TestFlight (#203), and then merge this.

[pkalita-lbl]

Oops, I see I have conflicts to fix. I will get to that later today.

[eecavanna]

Looks good! I found the PR description very helpful, both to understand the real-world context (i.e. motivation for doing this) and to understand various aspects of the diff.

I left some comments, including at least one that is to remind myself to look into something. I will re-read and act upon that/those right after I submit this review. Edit: I'm done doing that.