Show HN: Mixpanel Event Queueing Wrapper(github.com)
github.com
Show HN: Mixpanel Event Queueing Wrapper
https://github.com/skotzko/mixpanel-event-queue
2 comments
2 main reasons why I thought it was necessary:
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).
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).
[deleted]
This is my first open-source project. I was frustrated that Mixpanel did not natively include a queueing system for events (a la Google Analytics, KISSmetrics, etc) so I built one. Hope others find it useful and welcome any feedback.
You should probably use the magic arguments array in your function to avoid the ugly array you are using as the second argument.
_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();Ah, great point. Missed that. Updated and going to push update shortly. Thank you.
[EDIT] Pushed. Great catch, thanks again.
[EDIT] Pushed. Great catch, thanks again.
[deleted]
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