Add TCCP htmx extensions to handle cache busting and filter tracking

[contolini]

Adds two htmx extensions: One that adds an htmx query param to URLs immediately before htmx makes a request and then removes it before pushing it to the browser's history. This allows endpoints fetched via AJAX to have a URL that is different from their host page's URL, (hopefully) solving our Akamai issues. The second extension stores the filter page's
pathname to web storage so that our breadcrumbs can later retrieve it.

I also added a few cypress tests to detect future regressions.

How to test this PR

1. ./frontend.sh
2. Visit the cards page and open the dev tools network tab. Notice that when you change filters, the AJAX requests have htmx=true query params but the page's URL does not.
3. Type sessionStorage.getItem('tccp-filter-path') into the browser console and you'll see the most recent page's pathname with query parameters (to be used for breadcrumbs).
4. yarn cypress run --spec test/cypress/integration/consumer-tools/credit-cards/explore-cards.cy.js

Screenshots

Notes and todos

• You might sometimes see htmx:historyCacheError errors in your console. This happens when htmx's caching logic exceeds the browser's local storage limit. We don't have any control over this error and it's unrelated to this PR.

Checklist

• PR has an informative and human-readable title
  • PR titles are used to generate the change log in releases; good ones make that easier to scan.
  • Consider prefixing, e.g., "Mega Menu: fix layout bug", or "Docs: Update Docker installation instructions".
• Changes are limited to a single goal (no scope creep)
• Code follows the standards laid out in the CFPB development guidelines
• Future todos are captured in comments and/or tickets
• Project documentation has been updated, potentially one or more of:
  • This repo’s docs (edit the files in the /docs folder) – for basic, close-to-the-code docs on working with this repo
  • CFGOV/platform wiki on GHE – for internal CFPB developer guidance
  • CFPB/hubcap wiki on GHE – for internal CFPB design and content guidance

Front-end testing

Browser testing

Visually tested in the following supported browsers:

• Firefox
• Chrome
• Safari
• Edge 18 (the last Edge prior to it switching to Chromium)
• Internet Explorer 11 and 8 (via emulation in 11's dev tools)
• Safari on iOS
• Chrome on Android

Accessibility

• Keyboard friendly (navigable with tab, space, enter, arrow keys, etc.)
• Screen reader friendly
• Does not introduce new errors or warnings in WAVE

Other

• Is useable without CSS
• Is useable without JS
• Does not introduce new lint warnings
• Flexible from small to large screens

[chosak]

You might sometimes see htmx:historyCacheError errors in your console.

Indeed I do see this. It looks like HTMX saves the full page content into the history. According to this browsers can store up to 5 MiB per origin. Some of our pages can be more than 1MB (is this due to the repeated large SVGs for the dollar sign icons when we fetch 100s of cards into the table? is there some way to optimize this?) and so this fills up pretty quickly.

Is it worth setting hx-history to false to prevent the page content from being stored in cache? The URLs should still be, it's just that each page will need to be re-requested from the server (although they'll be cached in Akamai at least).

[contolini]

Is it worth setting hx-history to false to prevent the page content from being stored in cache? The URLs should still be, it's just that each page will need to be re-requested from the server (although they'll be cached in Akamai at least).

Works for me (c716050). Akamai edge caching should take care of everything.

Our page does have a lot of HTML when there are 400+ cards shown to the user but it's still smaller than other cf.gov pages (e.g. iRegs). If you're looking at the size of network requests, keep in mind that localhost isn't compressing anything so the same request on beta should be ten times smaller when gzip'ed. If page performance becomes an issue we can load ten results on page load and have the "show more" button dynamically fetch more.

[chosak]

If you're looking at the size of network requests, keep in mind that localhost isn't compressing anything so the same request on beta should be ten times smaller when gzip'ed.

@contolini thanks; I was looking at the size of the data in local storage, which doesn't get stored compressed:

Disabling the history works, though!

Thanks for adding Cypress tests - let's follow up in a subsequent PR to add test data for the detail pages.

[niqjohnson]

Working beautifully!