Add telemetry to frontend app

[silentninja]

Fixes #2502

Adds functions to log user interaction events. There is a slight change in the implemented infrastructure compared to agreed infrastructure in the sync meeting. I have added the details in the Technical Details section below

Technical details
We dispatch the logged user interaction events as a window event, which is then picked up by an event listener that is available in the demo mode.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the master branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[silentninja]

@kgodey I would like you to review the logged event name and metadata attached to the events and make sure they are sensible.

[kgodey]

I have one comment @silentninja

[kgodey]

What does page refer to here? It's a little vague so I'd prefer a more verbose name.

[silentninja]

@kgodey page refers to the screen/page where the event/action took place. Does the name event_location or source_page convey the intent better?

In case you want to understand the reason behind the page attribute. It is useful in case an action can be performed in more than one place. For example, we can create a Table from

• The schema overview page (/<db_name>/<schema_id>/) . The event will be opened_create_table and the associated metadata will be page: schema.
• The tables page (/<db_name>/<schema_id>/tables/). The event will be opened_create_table and the associated metadata will be page: tables.
  The page attribute is helpful if we want to analyse the preferred page to create a Table.

[kgodey]

Makes sense @silentninja. I would do something like "source": "schema_page" since not all starting points are pages (e.g. the record selector might be a source).

[pavish]

@silentninja This looks good. I have a couple minor comments.

Regarding the events, I know that simple analytics automatically tracks route changes. We have only one additional custom event here opened_schema.

I assume we'd add more events to provide us better insight. Is there an issue to track the events we want?

[pavish]

Can we change the name of this to userAction or something similar? event is too generic a term to use here.

@seancolsen, @rajatvijay Do you have any suggestions?

[silentninja]

userAction makes sense.

[pavish]

sa_event would be undefined until the async analytics script loads, so the function will throw.

Event listeners ignore any errors within them, so we don't have to worry about a DOM wide error. Also, we don't dispatch any event during that time so we probably wouldn't have any lost events.

I would still like some run time checks to ensure sa_event is defined, and e.detail is defined, and print a console error if not, to ensure we're aware of any future issues during development. Since we can't use typescript here, I feel that a runtime check would be good. This is a pattern I'd like to discuss @seancolsen @rajatvijay

@silentninja No changes needed in this PR. If we do introduce some pattern around this, we'll take that up later.

[pavish]

This does not have to be placed within onMount.

onMount only gets called after the component is rendered to the DOM. The logEvent function has nothing to do with the DOM, so we can directly specify it on the component.

[silentninja]

@pavish Thanks for the review. I made the requested changes

I assume we'd add more events to provide us better insight. Is there an issue to track the events we want?

We don't have an issue, I will one, it is on my list of things to do

[pavish]

Looks good!