Providing same object to multiple tracking calls causes problems

[ljwagerfield]

It appears that Angulartics mutates objects passed as parameters to eventTrack and setUserProperties calls. This results in malformed tracking information being sent to the analytic web service(s).

To reproduce:

var properties = {'foo': 'bar'};
$analytics.eventTrack('some event', properties);
$analytics.setUserProperties(properties);

This will result in the payload for the initial call being sent down-the-wire as the payload for the second call, at least when observing KISSmetrics. This includes timestamps, which caused the real problem for us.

[luisfarzati]

Good catch, thank you. Anyone feeling like submitting a PR for this?

[ProLoser]

Random questions:

• Why aren't you calling setUserProperties first?
• Does sending user props cause mutations?
• Instead of making every library that takes an object, clone the arguments just in case you choose to reuse it, what are your thoughts about you just doing $analytics.eventTrack('some event', angular.copy(properties)); instead?

[timelf123]

@ljwagerfield do you have any update/progress?

[websirnik]

I've also noticed that while creating own plugin. Here is the example of inconsistency from two different plugins.

// angulartics-segment.js
$analyticsProvider.registerSetUserProperties(function (userId, traits, options, callback) {
  try {
    analytics.identify(userId, traits, options, callback);
  } catch (e) {
    if (!(e instanceof ReferenceError)) {
      throw e;
    }
  }
});

--

// angulartics-mixpanel.js
$analyticsProvider.registerSetUserProperties(function (properties) {
  mixpanel.people.set(properties);
});

[timelf123]

I'm not really sure how to handle this. At one point we discussed wrapping analytics.js from segment since they abstract away all of the differences between providers.

@angulartics/core thoughts or do you remember our discussion from way back when?