Ember Tracking API Wishlist

ember-tracking-api-wishlist.md

#Ember Tracking API Wishlist

Control interaction hook

We need a general way to hook into when the user interacts with the app. Not entirely sure what this would entail, but at a high level, a non-exhaustive list of things that would need to be watched:

• link-to
• action
• any form element
  • Radio
  • Select
  • Text area
• clickable or swipable components
  • Declarative map mapping actions (click or swipe) to a string key passed to handler callback
• external links

Additionally, the hook would need to be passed any custom parameters or helpers passed to the element that was interacted upon. This is because we need to have identifiers for every control.

It may not be feasable to automatically watch all items listed. We also do not want to always watch some of these things, but we want the developer to be able to specifically opt-in to watching certain elements. For instance, the developer may want to get an event whenever a user focuses or unfocuses from a particularly important text field.

Route navigation hook

We need a hook that includes the following info:

• Origin route
• Destination route(s)* (if different from origin)
• Action that triggered change
• Element (with parameters) that was interacted with to cause route change. We need to be able to get the control identifiers from this info.

Destination Route(s)*

The route navigation hook needs to include info about the parent routes of the leaf destination route. We need to know which, if any, of the parent routes changed. For instance if you navigate from company/2/team/4/employee/6 => company/2/team/8/employee/9, the hook needs to indicate that the company route did not change, but the team and employee route did change.

link-to hook

We need a clean way to fire custom tracking events when specific link-to element is clicked. This can simply be a callback that's fired in the context of the parent component. Callback should also include a reference to any tags set on the link-to element.

Implementation Notes

We could potentially add a tracking queue to the run loop. Tracking events need to be in order relative to other tracking events, but they should be 2nd class citizens as far CPU priority.