Feedback/travel-pay/appt-sharing

products/health-care/beneficiary-travel/engineering/submit-claim/appointment-data-sharing.md

@@ -1,22 +1,49 @@
 # Appointment Data Sharing
 
-## The Problem:
+## The Problem
+
 Because the appointments list/details page lives in a different React app than the travel pay app, where SMOC lives, we need to pass the appointment details from the appointments app to the travel pay app. Because they are separate React apps, the redux store umounts and remounts when switching between apps (the appointments redux store doesn’t exist in the travel pay app, and vice versa) so we cannot store the data in redux during the transition as initially planned.
 
-## Proposed solutions:
+## Proposed solutions
+
+## notes
+
+Rankings each on a scale of
+
+(preferred)
+
+- Yes
+- Yes, with concerns
+- Hmmm, Maybe?
+- Rather Not
+- Hard No
+
+(least preferred)
+
+### Option 1
 
-### Option 1:
 Pass VAOS appt ID as url params (`travel-pay/new/{apptID}`) and call VAOS API module to retrieve appt details
-- Pros: 
-  - No refactoring of existing code, 
-  - we keep our own redux store, 
+
+### Thoughts
+
+Yes. API calls can be cached/made faster, this feels like the easiest; Would allow linking from any place, not just the appointment list
+
+- Pros:
+  - No refactoring of existing code,
+  - we keep our own redux store,
   - travel pay remains a separate entity
 - Cons:
   - Extra API call to retrieve data that already exists 😐
   - The data straight from the API would need to be normalized (this is currently handled in the appointments FE codebase) for use in the travel pay app
 
-### Option 2:
+### Option 2
+
 Pass BTSSS appt ID as url params (`travel-pay/new/{btsss-appt-id}`) and call TP API to retrieve appt details
+
+### Thoughts
+
+Rather not; because I want to try to hide internal btsss workings from VA.gov as much as possible
+
 - Pros:
   - BTSSS appt ID is required for SMOC submissions, so it eliminates that step from the submit steps
 - Cons:
@@ -25,32 +52,63 @@ Pass BTSSS appt ID as url params (`travel-pay/new/{btsss-appt-id}`) and call TP
   - this may be problematic depending on how long the appts plugin needs to run to pull appts into the BTSSs system
   - BTSSS appt object doesn’t contain the same data points that the VAOS appt does so designs might need adjusted
 
-### Option 3:
+### Option 3
+
 Pass appointment date-time as url params (`travel-pay/new/2024-11-22T11%3A00%3A00`) and call TP API to retrieve appt details
-- Pros: 
+
+### Thoughts
+
+Rather not; times can get weird. It was fine enough for PCI, but always felt unreliable. And timezone suck, double so with VA data
+
+- Pros:
   - Don’t make the API call until in the travel pay app itself
   - And would only call the BTSSS appts endpoint if the user chooses to submit a claim
   - BTSSS appt ID is required for SMOC submissions, so it eliminates that step from the submit steps
 - Cons:
-  - See Option 2 Cons 
+  - See Option 2 Cons
+
+### Option 4
 
-### Option 4:
 Move SMOC submission app into VAOS directory (`appointments/past/{apptId}/submit-travel-claim`) and use a React Router <Link> to pass the appt as a state object
+
+### Thoughts
+
+Rather not; This is unneeded overhead that we are going to addressing with creating 1 big MHV bundle (UAE + MHV + All The Things)
+
 - Pros:
   - Easier passing of data (can store in redux or pass as a `location.state` object
 - Cons:
   - Travel pay is unnecessarily intertwined with appointments app which could cause problems once we start work on complex claims
 
-### Option 5:
+### Option 5
+
 Add a platform level shared redux state store where the appointments app can drop the appointment into state for the travel pay app to retrieve
+
+### Thoughts
+
+Hmmm Maybe?; (assuming that the redux actually stores data) My only thoughts here would be is there a way to either
+
+- define a way to share data, like a sharedData bucket in the global redux to help solve this pattern across other apps
+- OR; Elevate health data into the global store.
+
+I think there is something here I will take to the Health Enigeering leads and converse and war game. Especially with the combination coming at some point there could be some things here. Still.
+
 - Pros:
   - Easier passing of data
 - Cons:
   - Requires platform level code changes (not terrible, but a consideration)
   - Per profile FE dev, this shared redux doesn’t actually store the data, each time it’s requested it still requires an API call (not confirmed by Liz as of yet, but sounds legit) so we’re still making an additional API call to get the appointment details
 
-### Option 6:
+### Option 6
+
 Implement the Forms Library and store the appt data on the BE as a Saved in Progress form
+
+### Thoughts
+
+Hmmm, Maybe? The idea of using the BE as a datasource could work. Just not using these systems. There could be a world in which we store the eleigible appointments in redis and query for those. This could be the optimization for Option 1
+
+Rather not; on the forms library.
+
 - Pros:
   - Easier passing of data
   - Forms Library and SIP would already be implemented and ready to expand for complex claims
@@ -59,15 +117,27 @@ Implement the Forms Library and store the appt data on the BE as a Saved in Prog
   - Would still require an API call to retrieve the SIP form
   - There are many unknowns as to whether or not it would actually work as needed 🫤
 
-### Option 7:
+### Option 7
+
 Push SMOC release back even further until the one-MHV-to-rule-them-all consolidation work is complete and both appointments and travel pay can live in one MHV directory
+
+### Thoughts
+
+Hard No; we ned to delivery something before the `one-MHV-to-rule-them-all`
+
 - Pros:
   - Shared redux store, shared routing, etc.
 - Cons:
   - Delivery dates will be adversely impacted
 
-### Option 8:
+### Option 8
+
 Cache the VAOS appt data in the vets-api redis instance. Upon user nav to the submit claim form, make a fast API call to pull the cached data
+
+### Thoughts
+
+Hmm, Maybe?; Looks like we got the same idea. I imagine we could do some smart caching here with the appointments team
+
 - Pros:
   - Yes, it’s still an API call, but fast. ⚡ 🦔
   - We have some control over how the data gets serialized/transformed before or after it’s cached
@@ -76,8 +146,14 @@ Cache the VAOS appt data in the vets-api redis instance. Upon user nav to the su
   - Requires Appts Team work to call the endpoint to cache the appt
   - Requires another API call on nav to submit
 
-### Option 9:
+### Option 9
+
 Store the required appointment data in local storage and pull it back out once the user has navigated to the travel pay app
+
+### Thoughts
+
+Yes. but with concerns; Session storage over localstorage; Could also store only what is Needed; Session storage management is real overhead could lead to some odd behavior is done not-perfectly.
+
 - Pros:
   - Appointment data would be available without additional API calls
 - Cons: