Fix search referrer bug

[JamesCGDS]

What

This PR contains two key changes:

• Fixes a bug where the referrer property on the page_view object was not updating correctly after dynamic page updates
• Adds a new dynamic property to the page_view object

Why

When a user is on a search results page and applies a filter, the URL of the page changes and PA's need to be able to track the URLs a user has visited using the page_view.referrer property. In the current implementation, however, the page_view.referrer property was not updating and remained the same whenever a dynamic update was triggered. This PR ensures that the page_view.referrer property is updated correctly by using a parameter that it receives from live_search.js in the finder-frontend repository.

In addition, PA's need to be able to distinguish between a fresh page load and a dynamic page update and the dynamic property has therefore been added to the page_view object. As requested by the PA's, it is a stringified boolean.

Visual Changes

None.

N.B.

Related PR - alphagov/finder-frontend#2906

As this PR changes how GOVUK.analyticsGa4.Ga4EcommerceTracker.init() receives and handles parameters, these changes are breaking.

[AshGDS]

Looks good to me, there's a small change needed for the CHANGELOG.

[andysellick]

Looking good, a few comments/mainly questions to help my understanding. I'd suggest merging the test commit into the code changes commit, as they're directly related (presumably the tests would fail without the code changes, and vice versa).

[andysellick]

You've covered all the possibilities of these two keys existing/not existing very thoroughly here. I'm just curious though - I thought that they're intrinsically linked i.e. if there's a value for referrer then dynamic is always true, otherwise both are missing. Can you explain the three scenarios being tested here?

[JamesCGDS]

I think this is sort of linked to the first comment - if we're happy with keeping the code as it is, this means that the referrer and dynamic properties are being conditionally set by different values on the dynamicPageViewData object and I'd just want to be absolutely sure that everything is working as it should in all possible scenarios

[andysellick]

Been wrestling with this over lunch. I think I'm coming around to the thought that this doesn't feel quite right - we're passing an object that contains two values, but only really using one of them (referrer). I'm quite happy to pass an object (it's more future proof, although I'm not aware of anything else we'd need to pass) but the code and tests currently imply that different values might be passed in that object, when in reality there are only two scenarios: nothing is passed, or referrer and dynamic (set to true) are passed.

[JamesCGDS]

Cool, thanks for this @andysellick. What I've done is I've changed the implementation slightly so that it's only using a single string parameter now rather than an object. Like you say, I'm not aware of anything further that would need to be passed and, thinking about it, I think passing an object when we only need a single value might not be the most intuitive. If this needs extending in the future we can make it an object but, in the interests of keeping the code more readable in its current form, perhaps just passing the string is best.

I've also made the corresponding change in finder-frontend

[andysellick]

Thanks @JamesCGDS, this feels much tidier 👍

[AshGDS]

Looks good, good spot on the things I missed @andysellick

I'd squash the commits once Andy has seen the changes

[JamesCGDS]

@AshGDS - cool, will do. Just kept the commits separate for the time being so it was easier to see the changes.

[andysellick]

Looks good, just need to squash some commits 👍