Draft: Resolve "[SPIKE] MR Widget Extension default telemetry"

For #358172 (closed)

Note: This is a spike, so may not cover every possible scenario.

Usage

A component extension will automatically track:

• "views" when the component is mounted
• expansions when the component is expanded
• clicks on the full report link

... in both the aggregate and for unique user counts (standard Redis counter and Redis HLL, respectively).

To disable this telemetry, a widget extension can provide data(){ return { "telemetry": false }; }.

NB: There is currently no way to opt out of individual telemetry events or add arbitrary events

How

The base widget extension includes telemetry that is added to the core behaviors (mount, expand, load full data) based on the widget name.

For example, if the widget is named WidgetThingReporter, the reported events will be i_merge_request_widget_thing_reporter_*.

NB: this uses simple pattern matching. If the widget name is WidgeThingreporter, the events will be i_merge_request_widget_widge_thingreporter_*.

Deeper

The telemetry helper uses a bus internally to abstract the reporting (currently just to Redis) away from the integration with components.

When a hub is created (createTelemetryHub), an object is returned (and stored in the telemetry data of the base widget) which exposes the setup .config and the internal .bus. Neither of these have any real use at the moment, but exposing them may provide hooks for customization later. The hub also exposes three methods: .viewed(), .expanded(), and .fullReportClicked(). Obviously, these can be called by anyone, but they are called by default in the base component's mounted lifecycle, toggleCollapsed method, and loadAllData method, respectively.

These methods emit a standard event into the internal bus (subscribers can arbitrarily also listen for these events, if desired, by subscribing to the exposed .bus mentioned above). Internal subscribers then send the appropriate events to the appropriate destinations (e.g. Redis and RedisHLL).

Deeper Still

Some existing components already used other event names for the widget expansion.

To handle this without an interruption in historical data, the telemetry bus combines multiple potential sources of events to publish and then iterates over them, publishing each to their intended destination.

As of this MR, there are only two sources: the default telemetry, which is constructed when the hub is created, and the "non-standard" (pre-generalized) events that are hard-coded and mixed with the default telemetry. The final result is exposed as .config on the hub itself (mentioned above in Deeper).

NB: the .config available on the hub is intended to be an inert copy of the actual config and is not consulted when publishing events. You can use it for review, but changes will not be reflected in the behavior of the telemetry. For now (before an actual immutable structure implementation is added) you can actually change the operation of the telemetry by modifying this config before UI behaviors occur.