How might we get a jump on delivering secondary nav?

[wesrowe]

Description

User story

As a Cartographers team member, I want to set us up to deliver MHV secondary navigation as quickly as possible after UX/UI design is finalized, so that we're ready for MHV-on-VAgov integration (all tools available on Ph1).

Notes

• How might we create a shared component usable in isolated applications? The Platform docs suggest src/site, but that doesn't seem used any more. Can we create in src/platform, and if so, can that be done "as quickly as possible"?
  • src/platform/user/profile/vap-svc is co-owned by vsa-authd-exp-frontend and has a module resolver alias of "@@vap-svc"
  • fwiw, a @@profile module alias points to ./src/applications/personalization/profile, but doesn't appear to be used by other applications
• Web component or React component? Could we deliver a web component quickly?
• If the ideal future is a web component in the design system, are there any considerations for our immediate/quick work?
• Likely way forward: Create PR to get Platform feedback on the shared-component approach

Acceptance criteria

• Got approval from Platform team on our recommended approach

Tasks

• [ ]

[dcloud]

Added some questions to the notes. It's unclear to me what prior art exists for a shared component created by a non-platform team and usable by isolated apps, but I believe it would exist in src/platform if it does. Maybe we could create src/platform/mhv or something similar?

Maybe good questions for the AuthExp team

[dcloud]

Added detail about @@vap-svc...

[adamwhitlock1]

@dcloud Here are a few thoughts that I have, but would be more that happy to meet up to discuss more about this type of thing:

• you can add code to the platform folder, but have to get it approved by the platform team. I don't know that there is a very formal process other than getting the PR put together and going from there.

• I do agree that having something like src/platform/mhv would make the most sense if this component will be a mhv exclusive thing, but that would also be a call I think platform teams would make

• the module alias of @@vap-svc is a relic of the past. Although it can still be used, I think adding more aliases for module resolutions within platform would be frowned upon and instead we would lean towards using just ~/platform/... or whatever the final location of the component happens to be.

  • An additional consideration is the fact that there are yarn workspaces set up to use package naming conventions like @department-of-veterans-affairs/platform-user for the platform/user location as an example. If you go with a mhv specific folder at the root of platform, then i think you would want to set up a similar structure and naming convention.
  • You could also just nest a MHV folder inside somewhere like the user folder, but will need add your exported components to the respective exportsFile.js to make sure that they can be accessed from applications.

• as far as web components go and prepping a component to be used in the design system

  • the main difference is that the web components are built in Typescript and use the Stencil framework to create the final components along with React bindings for their use. This is not something the vets-website is equipped to do at this time.
  • Making a React based MVP component and making it as flexible/documented as possible would be the best approach to getting something out of the door quickly and then working with the design system team to move that into TS/Stencil as time allows.

[carlosfelix2]

To expand on the note that the Platform docs suggest src/site as a location for a shared component:

• The platform docs mention that the src/site folder is for "assets used in applications." Website assets are generally defined as "any static content that are shipped intact to web browsers," which means that location will not match our desire for a web component.
• The platform docs mention that src/platform is for "shared code" which matches what we want to do.
• Furthermore, there is an existing folder src/platform/site-wide already present that looks to be the proper location for our shared code as there are other projects within that folder.
• And finally, there is already a src/platform/site-wide/mhv folder with a couple of utility functions. We can add our shared components there.

[radavis]

Agree w/ @carlosfelix2 that src/platform/site-wide/mhv is probably the best place for this. Imports would look like import { ComponentName } from @department-of-veterans-affairs/platform-site-wide, once adding our secondary nav component to src/platform/site-wide/exportsFile.js.

[carlosfelix2]

Our final recommendation is:

1. Location of the secondary nav code should be in src/platform/site-wide/mhv. We would add the typical web component folders to the mhv folder (e.g. components, constants, etc.).
2. Add the secondary nav component to src/platform/site-wide/exportsFile.js to make the import easier and be something like import { ComponentName } from @department-of-veterans-affairs/platform-site-wide
3. Preference will be to add ourselves as code owners for this folder. There are no other code owners for the existing code in that folder, but that existing code is small and rarely updated.
4. Should add these details to the initial implementation story.
5. Will not add code to the repo at this time as we do not want to introduce dead code which will probably result in comments to remove it anyways.

[wesrowe]

sounds very clear to me. this can close – I'll make sure to link the recommendation above in the implementation ticket.