EES 5633 - FE - Redirect the user to the latest version of a page if using an old Release slug in the URL

[jack-hive]

⚠️ This PR depends on some more BE changes we need to make on top of those in #5391. The new changes will be made in another PR under EES-5632. Please see #5446 to see those BE changes. [THIS PR IS BLOCKED BY #5446 ]⚠️

This PR consists of the frontend changes necessary to allow Release redirects to work.

Previously, we only had the ability to be able to redirect the user when we detected an old methodology/publication slug in the URL. But now, with the introduction of ReleaseRedirects in EES-5631 & EES-5632, we need to be able to handle redirects for releases too.

During this work, I had to refactor how the redirects worked on the frontend. Previously, we just looked for a prefix of either /methodology or /find-statistics in the URL and then checked if the next segment of the URL contained an old slug for either a methodology or publication, respectively, and then proceeded to redirect ANY child route.

However, this no longer works with the introduction of release redirects, because the current pages which contain a release slug in their URL also contain a publication slug. For this reason, if we only checked for the occurrence of a prefix in the URL before redirecting the user on any child route, then the release slug wouldn't be taken into account if we found a redirect for the publication. Equally, if we introduce any further routes in the future which contain multiple possible redirect slugs in their URL, they will be impacted too.

For this reason, I have refactored the redirect logic to only check for very explicit patterns in the URL, when trying to determine whether or not the URL looks like one that can be redirected. I've split out the 'URL Patterns' into a list, which can be iterated through and easily added to. We use the URL Pattern Standard to implement the matching logic, and use Regex to check for the various valid alternatives for a pattern (including checking for trailing slashes, which should be allowed). I have intentionally only included existing routes that need to be checked for redirects, and have not included subsequent child-routes that don't exist yet. Any new routes in the future, that have the potential to be redirected, can easily be added to the list of URL Patterns we check against.

Every (current) possible URL Pattern has been tested via Jest unit tests.

Other Related Changes

---

• Previously, the unit tests were importing and using the same instance of the redirectPages module throughout each test. However, due to the redirectPages module containing state in the form of the cached redirects (see the cachedRedirects property), this was being carried over between tests and potentially interfering. This hasn't been detected until now, because the previous tests, although mocking the response from the redirectService.list method, always returned the same mocked data from that method. So, the caching had no consequence to whether the test passed or failed. Now we have multiple test cases for each test, corresponding to each unique URL Pattern, it was necessary to use Jest's isolateModulesAsync to isolate specific modules for every test so that local module state doesn't conflict between tests (which was being flagged when doing the expect(redirectService.list).toHaveBeenCalledTimes(1); checks in the tests)

[benoutram]

I found it pretty tricky to review all of the different permutations that need to be tested but they seem to have all been covered and fall into the right categories! @jack-hive I'll just wait for you to review the additional comments I left before approving...