Unified SPA: Investigate how an another app (group), e.g. combined debt portal, were combined into to a single SPA

[wesrowe]

Description

User story

As a Cartography team member, I want to support OCTO's exploration of the unified-portal idea, so that a decision can be made about whether to pursue it.

Notes

• The slack canvas describes this effort as a proof-of-concept
• VA leads involved: @Stephen Barrs @Mark Dewey [He/Him] @Kaitlin Fink @Adrian Rollett

Possible tasks:

• Investigate how the existing combined debt portal was converted to an SPA. The existing combined debt portal was already converted to a single page application (SPA). Look into how was done and the possibility of reusing this pattern for the My Health SPA.

Acceptance criteria

• Document how was the combined debt portal was converted to an SPA.
• List any pros and cons of using this pattern, and/or if the pattern can be reused.
• List any features of this conversion and addresses any of the concerns listed in the Canvas for the My Health SPA investigation.
• Share findings with engineers

[dcloud]

Initial thoughts/notes

As I'm looking at this, I wonder if/how merging SPAs might interact with content-build vs next-build, though I'd hope its safe to assume that the different -build repos would treat app changes the same way.

First Steps

• Look at the PR that created the combined debt portal
• Examine current structure of combined debt portal code

[dcloud]

Further notes

From my in-progress notes

Current Structure

The src/applications/combined-debt-portal/combined/manifest.json tells us that the combined directory is the root app folder and combined-debt-portal is a path to collect the deb applications, debt-letters and medical-copays. The routes file imports from both those applications as well as from ./containers directory that has CombinedPortalApp.jsx. So the combined app both imports other apps into Routes and wraps everything in some common code.

CombinedPortalApp.jsx wraps the combined router and provides unauth redirects, downtime notifications, and service dependency checks (mvh, vbs, and dmc).

• src/applications/root-folder
  • combined-app, with manifest, that ties the apps together
  • app-1
  • app-2
  • app-x

App Isolation

An entry exists in config/changed-apps-build.json where "rootFolder": "combined-debt-portal". The structure of having a rootFolder that only holds other folders, combined, debt-letters, and medical-copays (where only combined has a manifest), may be in part a way to get isolated builds working with a nested structure. The MHV apps had issues with isolation from a shared mhv folder that housed multiple apps.

[dcloud]

When isolating the mhv applications, we saw issues with (CI?) tools not recognizing apps under certain paths, but that doesn't appear to affect combined-debt-portal, and it appears that the fact that the manifest JSON is in a subdirectory is fine.

Hoping to satisfy my curiosity and refresh my memory around directory structuring and app isolation, I went back to look for details on the issue we saw, but couldn't find anything about the errors. I did see that moving folders out of a shared src/applications/mhv was part of the approach, so perhaps that provides some answers.

[dcloud]

Work on combined-debt-portal

Combined Debt Portal Epic

1. Create new combined app (circa April 20, 2022) as a child under a new namespace dir that also serves as the name of record: combined-debt-portal. So the name of record matches the parent directory that contains the actual combined app
2. Create a CombinedPortalApp and add redux actions for fetching data: # 39369 - [CDP] - Establish API Calls for Data to Render (circa April 25, 2022)
3. Add "combined features", e.g. # 39372 [CDP] Your VA debts and bills Cards (circa May 6, 2022)
4. CDP Merge medical-copays under the new combined-debt-portal #21150 (circa May 24, 2022). Note that the app was copied and src/applications/medical-copays was not removed at this time
5. Copy debt-letters into combined-debt-portal CDP 41483 Merging Debt Letters under Combined Debt Portal #21148 (circa May 24, 2022). Note that the app was copied and src/applications/debt-letters was not removed at this time
6. Redirects for URL changes. The combined-debt-portal changed URLs
7. Removed debt-letter and medical-copay urls... (Dec 28, 2022) from ansible/deployment/config/revproxy-vagov/vars/react_routes.yml in devops repo – "configures whether routes ignored by proxy, allowing client-side routing such as react router"
8. Removed old debt-letters app: [CDP] - [LTR] - Remove Unused Applications #28542 (March 2024). Updates CODEOWNERS and deletes old app code
9. Removed old medical-copays app: [CDP] - [MCP] - Remove Unused Applications #28541 (March 2024). Updates CODEOWNERS and deletes old app code

[dcloud]

A highlight from the above "work on" timeline is that the combined-debt-portal put the new copies of debt-letters and medical-copays at different URLs, so the migration involved redirects.

We should think through how moving applications into a mhv-unified-portal might work without changing URLS. I don't think we want to change URLs for the MHV unified SPA, so we might have a tricky path to move an app, unregister it from the content-build, etc.

[dcloud]

Pros

• It creates a common area for shared code bits while keeping app-specific code folders
• Deduplicates a number of shared dependencies (React, etc.)
• ???

Cons

• Migration apps while maintaining URLs not addressed by combined-debt-portal example
• Your JS bundle will include dependencies and code not used across apps, e.g. PDF tools

[carlosfelix2]

One approach to change would be to keep the routes for each app in each app's folder and just have the unified app point to those routes. This way it will isolate the routing for each app to their own file and hopefully keep teams working in their own area.