As mentioned in this issue there is no way to time events independent of their name. This is a HUGE issue for any serious user of Mixpanel events because there is no way to follow the Best Practice Naming Guidelines and be certain your durations are correct.
For example, if I were to have a generic System event that I want to time as long as I have one of those events I'm fine, but if I ever need to time multiple system events there is no way for me to organize them or distinguish using Mixpanel which .track(event:) call matches with the original time(event:) call. This means that durations will be completely missing or inaccurate.
The that I'm adding in this MR is to link the tracking of timed events to an EventID instead of to the event name. That means callers of the SDK can provide their own unique id's for id's of events and be guaranteed that when the duration completes for that generic event the duration is completely accurate.
I added a new function signature for these timed and tracked events that allow users to provide a String eventID to link the two events. I would have liked to create a more type safe ID so that it's not just any string but because of the way the SDK works with events I didn't want to change too much besides separating the idea of an eventName with the idea of an eventID. I also separated out the idea of a TimedEvents dictionary from the InternalProperties dictionary that existed previously, this adds some small type safety around the dictionary and adds purpose clarity in the code.
The original method signatures still exist and work just as they did before they simply call the eventID versions of these methods so that there aren't two places that the logic needs to be maintained.
As mentioned in this issue there is no way to time events independent of their name. This is a HUGE issue for any serious user of Mixpanel events because there is no way to follow the Best Practice Naming Guidelines and be certain your durations are correct.
For example, if I were to have a generic System event that I want to time as long as I have one of those events I'm fine, but if I ever need to time multiple system events there is no way for me to organize them or distinguish using Mixpanel which
.track(event:)call matches with the originaltime(event:)call. This means that durations will be completely missing or inaccurate.The that I'm adding in this MR is to link the tracking of timed events to an EventID instead of to the event name. That means callers of the SDK can provide their own unique id's for id's of events and be guaranteed that when the duration completes for that generic event the duration is completely accurate.
I added a new function signature for these timed and tracked events that allow users to provide a String eventID to link the two events. I would have liked to create a more type safe ID so that it's not just any string but because of the way the SDK works with events I didn't want to change too much besides separating the idea of an eventName with the idea of an eventID. I also separated out the idea of a
TimedEventsdictionary from theInternalPropertiesdictionary that existed previously, this adds some small type safety around the dictionary and adds purpose clarity in the code.The original method signatures still exist and work just as they did before they simply call the eventID versions of these methods so that there aren't two places that the logic needs to be maintained.