Open mattflo-outpace opened 5 years ago
I can confirm. I've wired up a local build with line 265 commented out and it prevents the extra GET on the new url.
The only real purpose of track_links()
is to ensure that a tracking request can get out before the page unloads when a user clicks a link. So normally you just wouldn't use it for a SPA, since you can just fire off normal track()
calls in your click handlers or router functions.
That being said, if you prefer the track_links()
API of providing global selectors and want it to support this option, we'd be happy to accept a pull request.
Cool. That makes sense. We will continue to consider if this is the best direction for us to go and will consider a PR. Thanks!
Hi @tdumitrescu, as @mattflo-outpace mentioned, that is helpful.
Perhaps it's worth adding that we're working with a site where we're attempting to have them add our script to the page (which in turn loads mixpanel and tracks various events) without having direct access to the underlying codebase. If you have any suggestions for adding mixpanel to what is essentially a black box SPA from outside, those would be helpful, otherwise I think you're safe to close this issue. Thanks again for your reply.
We are trying to add link click tracking to our app which uses react-router and running into the same issue as @mattflo-outpace. Has anybody come up with a good work around for react-router links?
I'm noticing a strange behavior when I click a link wired up with
track_links
. It appears this code is breaking the single page application nature of our application by causing the browser to invoke a GET on the new url.https://github.com/mixpanel/mixpanel-js/blob/master/src/mixpanel-core.js#L248-L265
Maybe
track_links
needs to be able to accept an option that allows us to specify that the window.location should not be tampered with.