Allow async init

[romulof]

If we use the snippet, it creates a basic queue and loads the script asynchronously, so events can be tracked while the mixpanel lib is loaded. As a downside Adblockers can do their thing.

If we use the NPM package, we add 200kb of JS to our bundles and this cannot be loaded async unless we don't want to track things in background.

Loading async via NPM package can be tricky as different bundlers can handle things in different ways, although most use import(), so I suggest to make this initialisation in 2 steps:

1. Create a basic queue
2. Trigger the async load of the actual Mixpanel JS

Example:

import mixpanelInit from 'mixpanel-browser/init';

mixpanelInit(config, () => import('mixpanel-browser/lib'));

This way our bundlers can deploy mixpanel lib together with our applications, avoiding ad blockers, and we don't pay 200+kb bundle tax.

[bfricka]

FYI, I was able to make a custom version of this work. I created a modified version of the lazy loader snippet. It has the same API (although I rewrote it, and changed the actual implementation a bit), but instead of using a script tag, it uses an import('mixpanel-browser') statement.

I then tell Vite (our build tool) to alias 'mixpanel-browser', e.g.:

const alias = (modId: string, filePath: string) => path.join(path.dirname(require.resolve(modId)), filePath)

{
  resolve: {
    alias: {
      'mixpanel-browser': alias('mixpanel-browser', 'mixpanel.min.js'),
    }
  }
}

This file is the minified version of the CDN file.

Everything works, so there is no reason this can't be implemented by the mixpanel team. The only 'downside' is that my solution still uses the global window.mixpanel. The team could do away with this if they wanted to support it.

[romulof]

@bfricka, this way you are just bundling the version that is loaded by the snippet, which changes the global window.mixpanel object.

It will either increase your bundle size by ~50kB, if you do a synchronous import, or you'll have a blind spot until the asynchronous import is loaded, because until it is loaded there is no mixpanel object nor an event queue.

My proposal is for Mixpanel to make the basic queue the snippet creates available in the NPM package, while allowing us to connect our async loading mechanism (normally import() in any modern bundler, or plain browser ESM).

[bfricka]

@romulof Sorry, but you're completely wrong. The way I'm doing it has no blind spot, because the snippet code is a stub queue that handles all calls synchronously. These queued calls are then handled by the full library when it's loaded asynchronously.

It also doesn't increase the bundle size by more than the size of the snippet (which is just over 100 gzipped bytes), since the main library is loaded async.

But you seem to know better, so I guess you'll have to wait for someone to implement it for you.

[romulof]

@bfricka, alias('mixpanel-browser', 'mixpanel.min.js') will resolve to node_modules/mixpanel-browser/dist/mixpanel.min.js. If you inspect here, this file has 54.9kB.

And I don't want the snippet because it will load the main library from its original CDN, being an easy target for adblockers.

[bfricka]

@romulof You are obviously incapable of understanding how I implemented this, so again, you'll just have to wait for someone to do it for you.

[romulof]

I missed the "modified version of the lazy loader snippet" in your first comment, which defeats the purpose of requesting a feature here.

I'm not looking for a solution. My problem has been fixed way before I posted it here. I just wanted Mixpanel to be aware of the problem and proposed an easy API to solve the issue for everyone.