dotcom-rendering
dotcom-rendering copied to clipboard
Add logic to record existence of hidden front containers on page load
What does this change?
When checking if users have preferences for hiding front containers, this PR adds functionality to log the number of containers hidden (across all fronts) to Ophan.
-
If a user has local storage configuration to hide containers on any front, the number of container IDs currently configured to be hidden will be logged to Ophan
Example Ophan event payload for zero fronts hidden (where any previously hidden containers were subsequently un-hidden)
{ viewId: <page-view-id>, component: "front-containers-hidden", value: { numHidden: 0, namesHidden: [] } }
-
If a user does not have any local storage configuration to hide containers, no call to Ophan will be made
Why?
We are interested to know how many people use the show/hide functionality on web fronts.
Having analysed how many page views result in a click to show/hide an individual container, we will try to quantify this further by assessing how many users have current preferences to hide containers on fronts.
Caveats
There are several problems with this approach. The local storage solution is quite naiive and simply saves the front ID as the object key with either "opened" or "closed" as the value.
- This means that without checking the configuration items against valid, current front container IDs, we can't say how recently they were hidden or which front they apply to. For example, if you hide the "spotlight" container on the UK network front, any other front with a container ID of "spotlight" will also appear hidden whether that was the initial intention or not.
- If a front container changes ID, the existing configuration will not work, nor will it be removed since local storage items do not expire. This means that if the browser was not cleared of old local storage items, container visibility config could be very old indeed and may not represent current usage.