Add Log Entry / Calendar Symptom Shark Components

[chrisnowak]

Overview

This is a start to hopefully enable new MyDataHelps projects to incorporate Symptom Logging (Symptom Shark) more easily. Much of this has been copied from Symptom Shark and re-worked a bit to generalize it (and of course stories were added)

I organized these in storybook under a "SymptomShark" section that has presentation/container/view subsections. Stuff that felt functionally specific to Symptom Shark was put there (which is most of this) but some stuff (like NotesInput) was general enough that it was placed outside that library.

For basic reverse chronological logging and editing of logs there is:

• "LogToday" to display the current day's log (or prompt the user to log) for a "home" screen
• "LogEntryEdit" is the component for editing your symptom log
• "LogEntryList" is the reverse chronological list of symptom log entries

For visualization, I brought in all the functionality of the Symptom Shark "Calendar" view, including:

• The Symptom / Treatment Filters
• The Calendar itself
• The Symptom / Treatment Histograms
• The "Overall Experience Chart"
• The Symptom Severity Chart

I wanted these components to be easily drag/drop reorderable via the upcoming view builder. However, it doesn't really work from an efficiency/perf perspective for these components to fetch their own data - that would be very redundant since there could be a lot of these components on the page.

So I followed the "DateRangeCoordinator" pattern and created a "SymptomSharkVisualizationCoordinator" for the overall experience chart, symptom severity chart, calendar, and histograms to sit inside. SymptomSharkVisualizationCoordinator has a flag for "AllowFilters" which will show/hide the filters at the top as well.

SymptomSharkVisualizationCoordinator does the data fetching and renders it's child viz components when the data has been fetched. The visualization components get the data from the context.

Notable pieces of Symptom Shark not yet included (future PR):

• The "Setup Step" for setting up your symptoms / treatments (biggest blocker to self-service setting this up right now I think)
• The Report Builder for generating the PDF report of your symptoms / treatments
• The Device Activity View (this is not very symptom shark specific overall)
• "Questions for Doctor"

All the strings here are localized.

Some other notable tweaks / additions:

• I tweaked the default card border radius and dropshadow to match new designs @kyledehovitz-ce has been producing
• Cards have a couple new variants for "highlighted" and "subtle" to support some of the log entry stuff
• There is a new "NotesInput" component which supports automatic timestamping when you focus the input
• Segmented control supports 2 new variants "OptionsVertical" and "OptionsHorizontal", for a slightly more concise/condensed segmented control
• There is a new "Title" component for wrapping the H1, H2, H3 etc. (I used "order" of 1-6 to denote which one to render, following pattern from mantine)

TODO:

• Add view for SymptomDetail
• Add view for LogEntryEdit

Security

REMINDER: All file contents are public.

• I have ensured no secure credentials or sensitive information remain in code, metadata, comments, etc.
  • Please verify that you double checked that .storybook/preview.js does not contain your participant access key details.
  • There are no temporary testing changes committed such as API base URLs, access tokens, print/log statements, etc.
• These changes do not introduce any security risks, or any such risks have been properly mitigated.

Describe briefly what security risks you considered, why they don't apply, or how they've been mitigated.

Checklist

Testing

• MyDataHelps iOS app
• MyDataHelps Android app
• MyDataHelps website

Documentation

• I have added relevant Storybook updates to this PR as well.
• If this feature requires a developer doc update, tag @CareEvolution/api-docs.

Consider "Squash and merge" as needed to keep the commit history reasonable on main.

Reviewers

Assign to the appropriate reviewer(s). Minimally, a second set of eyes is needed ensure no non-public information is published. Consider also including:

• Subject-matter experts
• Style/editing reviewers
• Others requested by the content owner

[greinard]

That is clever.

[greinard]

Looks good to me. I played around in a story book quite a bit too. Everything seems to be working as expected.

[chrisnowak]

Thanks @greinard !