RFC - Ripple user events system

[dylankelly]

Summary

Create an event bus for recording all user interaction data, which each component can push data into and services can subscribe to.

Motivation

Why are you considering this? What issues are you trying to address? What other context does the reviewers need to be able to assess this?

Being used predominately for presentation heavy websites (consuming content rather than interacting with it), Ripple has never implemented a system wide State or event system (For example using Vuex). However Ripple is increasingly developing functionality in this area for example :

• Forms
• Search and filtering interfaces
• Data visualisation components which have user interaction, eg: maps
• Navigation without url change (eg menus)

Government has a strong desire to be able to capture user analytics data to be able to make informed decisions based upon how users are responding to SDP websites.

To be able to accurately report on user usage analytics, Ripple requires a way to expose user interaction events across all components. This system can then be hooked into when pushing data into analytics platforms (currently and for the foreseeable future this is using Google Analytics).

Having a documented API for every event a component emits, allows developers working with Ripple to more easily implement functionality that spans multiple components, allowing components to remain simple and abiding by the single responsibility principle https://en.wikipedia.org/wiki/Single-responsibility_principle.

Options

• Flux pattern (Vuex, Pinia)
• Event Bus
• Composables

Proposal

Please give a detailed outline of what the proposal is. This doesn’t need to be comprehensive, but should give enough detail to be implementable

• Create an event bus system which components can register events on.
• Components with interactions eg: Buttons, menus, etc should register an event handler and emit an event
• Export the event bus so analytics can subscribe to events and push into dataLayer

Benefits

List of the perceived benefits to the project for doing this

• Analytics events can be managed in a central place, allowing better easier testing and maintainability.
• Components have a documented set of events that they can emit and other components can subscribe to. This allows

Drawbacks

List out any potential drawbacks of doing this. Being realistic here creates a better picture of the what the challenges are

• Requires rearchitecting of Ripple components
• Creates a small amount of overhead (dependant on implementation)

Adoption strategy

Once this has been implemented, how do we drive adoption? If it’s a breaking change then how do you plan to address that? Does anything need deprecation?

TODO: Requires input on roadmap from Product team.