Add --whitelabel option to build process

[alexanderdean]

was: Add script manager as optional tag approach

As in part of build etc.

[fblundun]

I can think of 3 possibilities:

• The original script manager tag. This would makes sure that different versions of sp.js get loaded in the right order. It only works if both Snowplow users are using it - if only one is, it's no better than no script manager at all.
• Have a small tag without a script manager and a big tag with a script manager. The big tag would use something like setTimeout to make sure it works even if another user on the same page is using the small tag.
• Script managers are only necessary if there are multiple versions of sp.js. If our future sp.js custom build process allowed the Snowplow user to directly set their Snowplow namespace inside sp.js, we wouldn't need to make sure that different scripts load in the same order that namespaces get added to the GlobalSnowplowNamespace array, because there would be no need for a GlobalSnowplowNamespace array to tell sp.js the name of the queue it should be looking for.

[alexanderdean]

That's very interesting! I like option 3 - the idea being that we would mandate to widget companies that they come up with a custom Snowplow namespace... Could we have a grunt option which was something like --whitelabel=name

I'm not sure I understand the setTimeout in the big tag in option 2 - that sounds a bit scary.

[fblundun]

The idea with setTimeout is that every Snowplow user using the big tag would automatically wait some amount of time, e.g. 3 seconds, before changing GlobalSnowplowNamespace or attempting to load their version of sp.js, in the hope that the delay would give an instance of the smaller tag the head start needed to finish resolving first. It's admittedly not the cleanest approach - I'm sure there's a neater way to accomplish the same thing. Option 3 would make the JS invocation tag significantly shorter, too.

[alexanderdean]

Interesting - option 2 sounds rather non-deterministic and potentially very problematic to debug...

I say let's go with option 3 - I will rename this ticket.

[alexanderdean]

Let's wait and see how people use 2.0.0 first

[paulboocock]

This will be partially resolved by moving to ES Modules as users will directly import the tracker into their codebase rather than loading the script. However, for those still loading via a script the whitelabel option to create a different namespace queue seems easiest to fix this. We can consider this with V3 and the new rollupjs build process.

[dcarniel-evorra]

We're facing a similar issue when using the javascript tracker for our project. As we integrate it on different websites, we came across one that used v2 of the snowplow javascript tracker.

It caused issues which we tracked down to having the same window.GlobalSnowplowNamespace variable used by both versions.

Being able to build our own instance with such a "whiteLabel" option to change this global variable could work (we've done the change manually and it works but we'd rather have a properly built one ;-) ).

We'd be happy to contribute the change for the next release if that is still in the plans (and we manage to do it properly of course :-P )