WS-114: Consolidate Optimizely page metrics

[Isabella-Mitchell]

Resolves JIRA: https://bbc.atlassian.net/browse/WS-114

Summary

Combines Optimizely Page metric hooks to make it easier to devs to set up and tear down experiments

Putting up for early CR for thoughts/ opinions on approach. Have done some basic testing and it seems to work. Can/will do more.

Code changes

• Make root component for OptimizelyPageMetrics. Inside nests PageViewTracking, PageCompleteTracking and ScrollDepthTracking
• Moves isAmp check to top level
• Updates/ adds unit tests
• Updates to Typescript
• Updates implementation in ArticlePage
• Puts in a hacky fix for TS lint check making the github actions fail. (More context on slack)

Developer Checklist

• [ ] UX
  • [ ] UX Criteria met (visual UX & screenreader UX)
• [ ] Accessibility
  • [ ] Accessibility Acceptance Criteria met
  • [ ] Accessibility swarm completed
  • [ ] Component Health updated
  • [ ] P1 accessibility bugs resolved
  • [ ] P2/P3 accessibility bugs planned (if not resolved)
• [ ] Security
  • [ ] Security issues addressed
  • [ ] Threat Model updated
• [ ] Documentation
  • [ ] Docs updated (runbook, READMEs)
• [ ] Testing
  • [ ] Feature tested on relevant environments
• [ ] Comms
  • [ ] Relevant parties notified of changes

Testing

• [ ] Manual Testing required?
  • [ ] Local (Ready-For-Test, Local)
  • [ ] Test (Ready-For-Test, Test)
  • [ ] Preview (Ready-For-Test, Preview)
  • [ ] Live (Ready-For-Test, Live)
• [ ] Manual Testing complete?
  • [ ] Local
  • [ ] Test
  • [ ] Preview
  • [ ] Live

Additional Testing Steps

• Go to article page, e.g. http://localhost:7080/afrique/articles/cz0d00ld0lno?renderer_env=live
• Force self into experiment by setting isInExperiment in ArticlePage to true
• Open devTools console
• See console.log for Optimizely events.

Useful Links

• Coding Standards
• Repository use guidelines
• Add Links to useful resources related to this PR if applicable.

[Isabella-Mitchell]

I can't recreate this failing unit test locally... 👀 - still getting my head around it

[amoore108]

Is it worth having 'root' component that renders each metric component based on the props, like:

const PageMetrics = ({ pageComplete, pageDepth, pageView }) => {
  return (
    <>
      {pageComplete && <PageCompletes />}
      {pageDepth && <PageDepth />}
      {pageView && <PageViewTracking />}
    </>
  );
};

Just means each of them are quite isolated to one another, but still held within the same root component for re-usability.

[Isabella-Mitchell]

Is it worth having 'root' component that renders each metric component based on the props, like:

const PageMetrics = ({ pageComplete, pageDepth, pageView }) => {
  return (
    <>
      {pageComplete && <PageCompletes />}
      {pageDepth && <PageDepth />}
      {pageView && <PageViewTracking />}
    </>
  );
};

Just means each of them are quite isolated to one another, but still held within the same root component for re-usability.

I have gone with this approach. It seems easier to read