Custom tags for navigation events

Overview

Currently, it’s not possible to add a group ID (or tags) to navigations. I think navigations should be taggable since they’re used as aggregations downstream in DataDog.

A common pattern is to group events based on action/route/status etc. With navigations that’s not possible in a consistent manner.

Navigations do have a target field which defaults to the relative path for where the navigation is taking the user: e.g. /admin, /thank-you. This could and is used as group ID, but the problem is that some routes are dynamic, e.g. /order/123; or have long subroutes: /admin/settings/checkout/edit which requires route knowledge and can be error prone.

Not having a stable grouping ID has been a problem in the past and the approach was to parse target (a relative path), server-side:

• https://github.com/Shopify/web/blob/master/server/middleware/utilities/stats.ts
• https://github.com/Shopify/partners/pull/25877
• https://github.com/Shopify/partners/pull/26094

It seems that the complexity ☝️ can be dropped if the client can add grouping IDs (tags) to navigations.

How to do that?

Here are two possible approaches:

Add tags when navigations are created

One way would be to add tags when a navigation is created. That seems to happen here: https://github.com/Shopify/quilt/blob/master/packages/performance/src/performance.ts#L59. I’m not sure if this makes sense though, since navigations are created as callbacks to history API events (push,pop,replace). And thus the programmer doesn’t know where the user is taken.

Add tags when navigations complete

One way would be allow passing in tags to usePerformanceMark() which in turn calls Performance.finish().

My suggestion is to add the tags when the navigation completes, because this is triggered from the codebase as via usePerformanceMark() and thus the programmer knows which React page is being rendered.

Automatically apply tags to StatsD metrics

By default, koa-performance and quilt_rails (which process the browser performance reports) won’t apply tags on the navigation distributions, this can also be automated as part of this feature extension. This way users don’t have to apply logic like: https://github.com/Shopify/quilt/blob/master/gems/quilt_rails/test/quilt_rails/performance_reportable_test.rb#L170-L208.

Type

• Changes to existing features

Motivation

I’m trying to add browser perf. metrics to shop.app but some of the routes are dynamic and therefore they won’t aggregate properly in DataDog. My options are to do what other teams have done previously - post-process the routes server-side or allow tagging navigations on the client.

Checklist

• Please delete the labels section before submitting your issue
• I have described this issue in a way that is actionable (if possible)

[lemonmade]

I think I mentioned it above, but if this is an important feature to you, you can definitely implement it, and I am sure that the web foundation team will happily review. There is a place where I think the logic you are talking about makes sense (in usePerformanceReport); I don’t think it will ever be a priority for the web foundation team, but we hope that features that are priorities for individual projects/ subsets of projects can be added by developers on that team.

Up to you how to proceed, just don’t want to make this sound like a very final, “we will never add this feature” kind of discussion 😃

[lazarmarkov]

Putting tags on usePerformanceMark means that the tags are not then applied to other constructs, like events.

Yeah that’s a good point. I guess usePerformanceMark is not the correct place to put it. The problem is that since events/navigations are browser event based, it’s not possible to bind them to a certain path of the codebase (e.g. React page). Instead we’d have to backfill any additional data by determining which page is an event/navigation related to. And that bring us back to square one which is parsing the path.

Thanks for the comments, Chris!