Add the Event Specifications plugin

[igneel64]

No description provided.

[bundlemon]

BundleMon

Files added (6)

Status	Path	Size	Limits
✅	libraries/browser-tracker-core/dist/index.mod ule.js	+26.51KB	27KB / +10%
✅	trackers/javascript-tracker/dist/sp.js	+25.1KB	25.5KB / +10%
✅	trackers/javascript-tracker/dist/sp.lite.js	+15.4KB	16KB / +10%
✅	trackers/browser-tracker/dist/index.umd.min.j s	+15.29KB	15.5KB / +10%
✅	libraries/tracker-core/dist/index.module.js	+13.36KB	15KB / +10%
✅	trackers/browser-tracker/dist/index.module.js	+3.51KB	5KB / +10%

Total files change +99.17KB 0%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history

[matus-tomlein]

I like this, seems like a nice solution!

Just one question, did you consider having a typed interface for the EventSpecificationsPluginOptions constructor parameter? Currently users can pass Record<string, string> for the specific plugin events, which opens room for typos (e.g., play_evnt) and doesn't show the users what are the available options. It is more flexible for us this way, so it's a trade-off, just wanted to hear your thoughts on that.

[matus-tomlein]

Nit: extra return

[igneel64]

Just one question, did you consider having a typed interface for the EventSpecificationsPluginOptions constructor parameter? Currently users can pass Record<string, string> for the specific plugin events, which opens room for typos (e.g., play_evnt) and doesn't show the users what are the available options. It is more flexible for us this way, so it's a trade-off, just wanted to hear your thoughts on that.

Good call!
The thinking is that this plugin input will never be typed by the user. It will be retrieved directly from the console like the following:

This is also mentioned in the README and will be added in the documentation page as well.

This configuration should be retrieved directly from your Data Product in the Snowplow BDP Console.

Does it make sense?

[matus-tomlein]

That makes sense! If it's going to be primarily used by copying from Console, then it should be fine this way.

Except for the one potential problem that I commented, this LGTM!

[matus-tomlein]

Why do we consider all integrations here? For instance if the user configured the plugin like this:

EventSpecificationPlugin({
  OtherPlugin: { play_event: "wrong" },
  SnowplowMediaPlugin: { play_event: "correct" },
})

And the current event was matched against the media plugin, wouldn't this code result in the wrong ES ID being taken?

This can't happen now since we only have one integration, but if there is such a problem, it would be good to solve it before we add more integrations.

[igneel64]

Yeap, fixed:

const matchingPluginEventMap = options[integrationKey as AvailablePlugins];
const matchingEventSpecificationId = matchingPluginEventMap && matchingPluginEventMap[matchedEvent];
if (!matchingEventSpecificationId) {
    return;
}

Plus both integrations and options can only have AvailablePlugins as keys

[matus-tomlein]

looks good!