Single Page Application Page View Tracking

[gregjhogan]

Single page apps (such as AngularJS) need an easy way (using publicly documented APIs) to change the Operation ID each time the SPA changes the route.

[AlexBulankou]

@gregjhogan regarding your comment on the related issue, where you said the roadblock for you was to find how to renew operation ID. Would this be easier for others we added documentation educating users on the possible (I hesitate to say "recommended", because it is not universal) approach of renewing operation ID when SPA page transition starts.
Basically a section on the homepage on SPAs. Would it help?

[gregjhogan]

Yes, for example should we use Util.newId, or the Operation constructor (both of which are not in the public documentation)? Also, I hope that creates a commitment to keeping the AI side of that integration stable. Thanks!

[RichiCoder1]

Old issue, but I'd personally love to see some official docs on SPA + AI integration.

[jsgoupil]

I need to set this operation id differently.

In some does, it's mentioned that to track the POST data, we need to send a trackTrace. But it doesn't talk about this operation id. After a lot of searching, I figured out that the operation id has to be the same here. The AJAX requests are automatically tracked, and when they fail, I issue a trackTrace the POST body. However, I don't have this operation id. This is quite complicated for tracking requests together here.

[boydc2014]

So, in 2018/7/5, do we have a method to renew OperationID for SPA at each route change

[andrejpk]

I agree that this needs better integrated tooling. This is a very common scenario and we shouldn't need a hack to make this work as most would expect.

That all said, here's my hack for my tracing to put a new operationId on each client-side route navigation (here in an angular.js app in Typescript):

      const ApplicationInsights =
        window['Microsoft'] && window['Microsoft'].ApplicationInsights;
      if (ApplicationInsights && appInsights && appInsights.context.operation) {
        appInsights.context.operation.id = ApplicationInsights.Util.newId();
        appInsights.context.operation.name = toState.name;
      }
      appInsights.startTrackPage(toState.name);

[pviotti]

For React apps you can try react-appinsights: https://github.com/Azure/react-appinsights
There's a beta version of react-appinsights supporting the upcoming AI SDK 2.0 that you can install with npm install --save react-appinsights@beta.

[mdressel]

@pviotti I have tried the latest React Extension (https://github.com/microsoft/ApplicationInsights-JS/blob/master/extensions/applicationinsights-react-js). It doesn't seem to address this specific issue.

While it is fairly easy to implement with the example application, all of the requests being tracked are considered the same operation as you can see below. I am not sure if I am just using this wrong or if I need to develop my own version of the extension that would utilize similar logic to what @andrejpk provided.

If this is an issue witht he applicationinsights-react-js extension, I can log a specific issue.

[MSNev]

Adding for completeness that currently in v2.x the approach currently is almost the same as v1

      if (appInsights && appInsights.context && appInsights.context.telemetryTrace) {
        appInsights.context.telemetryTrace.traceID = generateW3CId(); // <- Sets the new Id using the generate W3c helper function 
        appInsights.context.telemetryTrace.name = toState.name;
      }

[MSNev]

As part of #1705, I'm abstracting the distributed tracing support and providing another way of setting the traceId, spanId and traceFlags directly on the AI instance.

Under the covers it will still be setting the appInsights.context.telemetryTrace values, so both the above and the new functionality are identical.

The new approach will be appInsights.getTraceCtx().setTraceId("..."), the only real difference is that this will also validate that the ID is a W3C compliant traceId before setting it.

[MSNev]

Splitting out from the previous PR and linking to #1846

[johnib]

Why different page views of the same session should be considered as different operation?

[MSNev]

This is generally used to separate page views in the portal for SPA, the values are set / updated here via the code listening to the location change events.

What is your expectation for multiple page views with a SPA?
As the alternative would be to set the "spanId" (using the underlying parentID) so that all of the traces (events) from the same page are linked?
Additionally, as a session is persisted across multiple page views (via cookies if enabled), this would also become problematic identifying different page views in the portal...

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.