update handler for legacy component events

[micahchiang]

Description

This pull request fixes an issue in production where the footer accordion isn't opening properly for pages built with Next Build. This change removes an if statement that wasn't working anyway because of a syntax error, and replaces the check with a promise that waits for document.readyState: 'complete' if it isn't already that value.

We can't use readyState: 'interactive' because event listener attachment doesn't play well with that, and we can't rely on DOMContentLoaded because it doesn't work as expected with NextJS. Instead, we wait for readyState: 'complete' to ensure all assets are loaded properly, and then we register listeners for the legacy accordion, sidenav, and additional info components.

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

⚠️ TeamSites ⚠️

Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the #sitewide-public-websites Slack channel for questions.

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

• (Summarize the changes that have been made to the platform)
• (If bug, how to reproduce)
• (What is the solution, why is this the solution)
• (Which team do you work for, does your team own the maintenance of this component?)
• (If using a flipper, what is the end date of the flipper being required/success criteria being targeted)

Related issue(s)

• MUST: Next-build: Mobile footer accordions do not open when clicked va.gov-cms#20159

Testing done

• local testing on vets-website, content-build, proxy-rewrite, and next-build
• Note on Next Build testing: Local dev between vets-website and next-build is still work in progress, so the way this was tested in next-build was by copying the generated folder in vets-website to the same folder in next-build/public/generated, which is currently pulled from vets-website prod s3.

Screencaps

NB:
Screencast from 12-30-2024 12:05:14 PM.webm

vets-website:
Screencast from 12-30-2024 12:05:47 PM.webm

content-build:
Screencast from 12-30-2024 12:11:07 PM.webm

proxy-rewrite:
Screencast from 12-30-2024 12:21:48 PM.webm

What areas of the site does it impact?

VA.gov footer

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

[Andrew565]

Looks like the old code was looking for document.readState instead of document.readyState, was there any testing done to see if just fixing this typo effected the same change? Just curious.

[micahchiang]

I did fix the typo but found some unexpected functionality was introduced. Specifically, in this if statement, readyState will always evaluate to interactive which led to a weird race condition where handlers weren't actually attaching properly. Because of this, I just went with a refactor.