Support for Named Exports

[fforres]

I came across this while implementing Typewriter on an internal project. After doing some manual refactoring a few times I think it'd be great to have this baked in into Typewriter.

Currently typewriter exports wraps all your tracking calls inside a class you can instance to execute and allows you to pass an analytics instance.
i.e.

Current Status

Show

const genOptions = (context = {}) => ({
  context: {
    ...context,
    typewriter: {
      name: "gen-js",
      version: "5.1.1"
    }
  }
});
export default class Analytics {
  constructor(analytics) {
    this.analytics = analytics || { track: () => null };
  }
  someThingToTrack(props, context) {
    this.analytics.track("Tracking a Thing", props, genOptions(context));
  }
  (... Many other methods)
}

We where using only a few of those tracking methods in our specific project, so we where shipping a lot of unused code that we weren't able to treeshake.
While it might not look like a a huge code reduction if we add the --runtimeValidation false flag, but it is if we want to keep those 😢

So after talking with @colinking on slack, he mentioned making this issue could be a good first step into the discussion.

Proposal

Final export (after running typewriter gen-js with some flags i.e --runtimeValidation false --export class) would look like this:

Show

let analytics = (window && window.analytics) || { track: () => null } 

export const setaAnalytics = (newAnalytics) => { analytics = newAnalytics }

const genOptions = (context = {}) => ({
  context: {
    ...context,
    typewriter: {
      name: 'gen-js',
      version: '5.0.1'
    }
  }
})


export const someThingToTrack = (props, context, callback = () => {}) => {
  analytics.track('Tracking a Thing', props, genOptions(context), callback)
}

Explanation

• Implements a new flag --export with parameters class & named-exports (or functions?)
  • We set class as the default value for it to keep backwards compatibility
• Makes every method now a named export
• Enables a module variable to be the instance of analytics.js
  • Adds method to be able to override that variable
• Adds support for the callback parameter

Final Thoughts

• Easier tree shake / dead code elimination
• Yei for smaller bundle sizes ❤️

[colinking]

Thanks for raising an issue on this, @fforres!

A few questions:

1. From:

While it might not look like a a huge code reduction if we add the --runtimeValidation false flag, but it is if we want to keep those 😢

Are you all looking to keep the runtimeValidation code in, during production?

2. How much (in % Kb) would this remove from your bundle?

3. Just to clarify in this issue (I think we've discussed this privately), there are probably two scenarios of extraneous code here:

• a) Extraneous calls that are in your JSON Schema / Tracking Plan, but are not currently implemented
• b) Extraneous calls that are used on /page/a but not on /page/b, and you want to be able to tree-shake these calls from the bundle for /page/b

If the goal of this solution is a), then I would recommend using an event whitelist, since a native solution for whitelisting is on the roadmap (via a versioned lockfile).

But IIUC, you're only worried about b), right? In that case, I'd defer to questions 1) + 2) :)

[fforres]

Are you all looking to keep the runtimeValidation code in, during production?

Not in our case, no. Now that I think about it, maybe is not something that people would do in their prod bundle.
On the same point, and I might be derailing the conversation. Have we considered doing something like what react does for code elimination?
When bundling their library they look at the env variables and removes all the warnings/dev-only code if NODE_ENV=production, we can keep the warnings on dev and remove them on prod bundling

2. I'd have to test that. I'll bring some data in a bit :p
   Also, unsure on the size across different plans / users. Maybe our specific tracking plan is small enough that is not important?
   But since our tracking plan is not tied to only one project, It'd be great to allow for the bundling pipeline to make that call for you.

3. b

I think we can bring more data to make a proper decision, while for a some of our tracking plans it does feel small enough to be negligible, I'm unsure of the impact on some other users / different tracking plans here 🤔

[fforres]

❤️ @colinking you rock!! :D
Just looked at TW 2.0
Kudos!! :D

[colinking]

❤️ @fforres

HMU if Brex is interested in trying out Typewriter!

[fforres]

We are.
I'm a big advocate for protocols / define our tracking-plan ( and tw specially 😄 )
It's taking me more than I hoped for to get someone that can help us with that 😅,
but we are getting there 🤘