Show HN: Mixpanel Event Queueing Wrapper(github.com) |
Show HN: Mixpanel Event Queueing Wrapper(github.com) |
If you use the integration code demonstrated in their docs here: https://mixpanel.com/help/reference/javascript, Mixpanel already has an event queue natively.
It sets the `mixpanel` variable to an array which which holds the event queue. It then defines functions on this array with the same names as those in the full library. When any of them are called the call is added to the event queue array.
When the full library loads, the array of queued events is placed in a temporary variable. The full library is loaded into the `mixpanel` variable and then the the queue is replayed by the full library.
analytics.js also works in this way
1) It's not clear at all by reading minified code that this is what's going on -- I could only really see it when I got my hands on unminified code. Since not covered in the docs, it's just hard to know.
2) It has tightly coupled queueing and loading of the library, which I don't want: the snippet links instantiation / fetching of the library with the queueing function and wraps them all together so they can't be separated in the overall page load sequence. Combined with the fact that Mixpanel does not use as simple of a data structure as something like GA (simple array), I wanted a way to separate queueing (what my wrapper does) from later instantiation. Granted, the Mixpanel snippet is async but at the time of writing this, we didn't want to source our external JS in the head of our pages if at all possible. So even with the built in async / queueing structure, the Mixpanel snippet still doesn't fully meet what we're looking for (separation of queuing / instantiation).
_meq.push("track",["event_name",{property_name: "value"}])
_meq.push("track","event_name",{property_name: "value"})
mixpanel: function() {
var mixPanelArgs = Array.prototype.slice.call( arguments );
var functionName = mixPanelArgs.shift();[EDIT] Pushed. Great catch, thanks again.