Discovery: prep plan for Drupalizing footer, based on megamenu header implementation

[jilladams]

Description

We want the Footer to be driven by Drupal, without any visible change to users. This ticket should capture the tasks / scope of work to migrate to Drupal, including:

• Create a Drupal menu to house footer-links.json
• Integrating that Drupal menu into front-end templates
• Thinking about how to structure the menu, to handle desktop columns & stacking for mobile, as well as the "bottom rail" (Accessibility, etc)

Not included in scope:

• Migrating Language links into Drupal. Those are driven by a React widget & can stay that way

Additional context

1. The header is driven by a Drupal menu: https://prod.cms.va.gov/admin/structure/menu/manage/header-megamenu
2. A footer menu exists that isn't populated but could be used for this purpose: https://prod.cms.va.gov/admin/structure/menu/manage/footer-bottom-rail
3. Content-build static data for most of the footer URLs: https://github.com/department-of-veterans-affairs/content-build/blob/main/src/platform/static-data/footer-links.json
4. Languages menu, driven by vets-website: https://github.com/department-of-veterans-affairs/vets-website/tree/main/src/platform/site-wide/va-footer

Acceptance Criteria

• Meet with Ryan, Jill, Wes for context and performance notes
• Review the megamenu templates for any gotchas / learnings
• Backend: Scope the changes required to render the footer from Drupal
• Frontend: Scope the changes required to render the footer from Drupal, including:
  • Mobile considerations
  • React and non-react options
  • Level of Effort for the options
  • Performance implications, especially re: React / non-React. (Let's harness the info we've gathered around React performance from talks with Design System / check-in experience)
  • How we would go about analyzing performance
• Review findings with Wes, Jill, DaveP
• Cut tickets for implementation work, into the Drupalize VA.gov Footer epic (Drupalize VA.gov Footer #10339)

[chri5tia]

#10512

Header Megamenu Explore for Example

CMS Architecture & Build

Created using the core menu module, doesn't look any different than usual on the backend:
https://va-gov-cms.ddev.site/admin/structure/menu/manage/header-megamenu

Block

For fully CMS-driven, menus get a block that are placed in block layout. Not needed for this since it's a FE controlled build.
Block name=headermegamenu

Templates and Frontend

Some of the important FE components to look at:

• Build plugins for header-footer: create-header-footer.js (line 16 generates va.gov/generated/headerfooter.json)
• content-build/src/site/stages/build/drupal/menus.js starting at line 164
• GraphQL navigation fragments for the header mega-menu:
• header.nav.graphql.js
• menulinks.nav.graphql.js
• Includes:
• top-header.html
• header.html
• Testing unit: mocha-setup.js
• eslintrc.js line 12
• drupal liquid templates

Footer Megamenu

Backend Conclusion

Footer Should be an easy lift with nothing special for BE.

• Cut ticket to populate existing footer menu with the links and hierarchy as seen in the footer on va.gov with non-link headers to break it up.

Footer menu started already in CMS

https://va-gov-cms.ddev.site/admin/structure/menu/manage/footer

Mentioned in:

• drupal liquid templates
• silvesmith
• includes

Current Footer used on site

Links are populated via content-build/src/platform/static-data/{}footer-links.json

...snip...
  {
    "column": 1,
    "href": "https://www.va.gov/womenvet/",
    "order": 2,
    "target": "",
    "title": "Women Veterans"
  },
  {
    "column": 1,
    "href": "https://www.va.gov/centerforminorityveterans/",
    "order": 3,
    "target": "",
    "title": "Minority Veterans"
  },
...nip...

Use this as a guide for populating the CMS footer.

Questions for sync call

• Content? What needs to be put in the menu:
• • links?
• • other stuff?
• Who needs access? Built by editors or developers?
• Context and the what/why
• what is megamenu
• how is the footer built now?

[jilladams]

@chri5tia the Header Megamenu reference is re: "Additional Context" #1 in ticket body -- The header is driven by a Drupal menu: https://prod.cms.va.gov/admin/structure/menu/manage/header-megamenu

Confirming: "Megamenu" is just internal lingo to refer to the Header and all its tendrils.

[jilladams]

Notes from sync with Christia, Ryan, Wes:

• Drupal path is pretty clear, @chri5tia will write that up or expand / edit the notes above.
• This ticket was originally framed to include the front-end research as well, but we didn't factor that into Sprint 70 capacity / assignment. So: Ryan has some time to take a look, but the front-end portion may roll over in to Sprint 71. @ryguyk has some time to start this, so assigning him here.
• Front-end: we need to write up the options for how to implement Drupal menu in the front-end, including:
  • Mobile formatting considerations
  • React and non-react options
  • Level of Effort for the options
  • Performance implications, especially re: React / non-React. (Let's harness the info we've gathered around React performance from talks with Design System / check-in experience)
  • How we would go about analyzing performance

Updated ACs to break this up.

[chri5tia]

Created drupal ticket: #11438

[chri5tia]

@ryguyk So you don't have to reinvent the wheel, I put a little information about what I could see about the FE header megamenu components, if it's more efficient for you to build on/add on to that.

I think my contribution to this ticket is complete.

[jilladams]

Re: #11438 , Christia noted that the 3 sections of the menu will get named within the menu itself, and that naming isn't decided. One thing for Front-end consideration (fyi @ryguyk ):

The "Section" labeling will be actually in the menu as top-level hierarchy, meaning it can be edited in Drupal.

That menu content will then go through to front-end and be used to layout the markup, since we decided to keep all 3 footer sections in one menu. So: that top level of the footer nav will be meaningful in the markup. We need to make sure the front-end build is resilient to any Drupal edits. Meaning: if we initially call the sections "Section 1, 2, 3" and someday rename them to "Footer subnav 1 2 3", we need to make sure that won't break the front-end

I don't know how the menu will pass through as GraphQL, if there will be an immutable handle to use for the sections, rather than the entered content. We won't be able to prevent someone editing it in Drupal, and we don't want that to break the footer, so: if entered content name matters, we may want to reconsider using 1 menu rather than 3 menus.

Lemme know if that makes sense.

[jilladams]

(presumably this is also true in the header already, and won't be an issue. Just flagging for awareness.)

[ryguyk]

Created #11482 to capture the eventual implementation. Refinement of that ticket will depend on architectural decisions related to concerns documented below:

Front End

• Mobile formatting considerations
  • The current React approach handles the differences between mobile and desktop design. If we move forward with the current React implementation (which is the suggested approach), this should not be a major concern.
• React and non-react options
  • React
    • This is how the footer is currently built. The easiest and suggested path would be to continue with this approach.
    • Currently, the React-based footer is generated from a json file that defines the links. We would need to do one of two things:
      1. Implement logic to create this exact json structure by translating the data from the Drupal menu.
      2. Generate a json file with a new structure (possibly more natural to the structure of the Drupal menu) and update the React code to process the new format.
  • Static Generation
    • It is likely possible to generate the html for the footer entirely during content build, but it would be a significant lift, as it would be a complete overhaul of how things are currently done.
    • "Language Assistance" is likely, at best, an exception, and, at worst, a blocker to static generation. See additional info below on this piece.
    • There is JavaScript code that is connected to link clicks, and this code would likely have to be converted from React to plain JS.
• Level of Effort for the options
  • React
    • Moderate ~8
  • Static Generation
    • High (much higher) ~21+
• Performance implications, especially re: React / non-React. (Let's harness the info we've gathered around React performance from talks with Design System / check-in experience)
  • React
    • Need to load React library.
    • Browser responsible for generating html, so there's delay.
    • Notably, again, this is how things are already being done. Drupalizing should have effectively no bearing on this. That is to say, Drupalizing the footer and keeping the React approach would not significantly change performance from what it is without being Drupalized.
  • Static Generation
    • Even if the footer doesn't use React, the React library will still be loaded on every page. Moving one component away from React would not change that without some significant restructuring
    • Some javascript code still required, likely, though not to generate html.
    • Html would (at least mostly) be generated during content build and downloaded by browser. Browser not tasked with generating html.
    • This would likely result in a slightly better user experience, though it's likely very small with the React library loading regardless.
    • However, this would put more stress on content build. In a perfect world, static generation would always be preferable, but we are currently already battling concerns of our content build growing beyond acceptable limits.
• How we would go about analyzing performance
  • Again, Drupalizing does not significantly change current performance. Moving away from React is a much bigger issue than anything related to Drupalization of the footer. Analyzing performance of such a decision, similarly, goes much beyond this issue.

"Language Assistance" Links

This section of the footer menu involves a React component that has more going on than what it might appear on the surface. The links are generated from some configuration around supported languages, and, additionally, clicks on these links have effects that seem to extend outside the footer alone. It is almost certainly the case that these links will not be included in the first pass of Drupalization (if ever).

[wesrowe]

Dave note:

• de-scope language links for now
• cut ticket to figure out a better approach for this

[jilladams]

Per sprint planning with Dave, approved to move ahead with React for now. @ryguyk to update #11482 with implementation notes.