-
-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixpanel types #116
base: master
Are you sure you want to change the base?
Mixpanel types #116
Conversation
- Move the mixpanel load script to separate file - Modify the load script to be able to specify which context object the mixpanel instance should be loaded. Defaults to `window` for backward compatibility - Add `context` mixpanel plugin config option that specifies the context that's passed the refactored load script - Update hooks to get mixpanel instance from resolveMixpanel function instead of from `window`. This decouples the use of mixpanel instance from the window object
- Add option to be able to pass a mixpanel instance directly to mixpanel plugin instead of fetching it from mixpanel CDN
- Add option to pass Mixpanel config - The config is passed to mixpanel.init if the instance needs to be instantiated - The config is passed to mixpanel.set_config if the instance already exists
- Add option `pageEvent`, which allows to specify the name of the event that's tracked when mixpanelPlugin.page is called. Defautlts to 'page'
mixpanelPlugin.page
…able - If 'mixpanel-browser' npm package is installed, the @analytics/mixpanel plugin will try to use that if a mixpanel instance doesn't exist yet
current mixpanel instance
- Add ./scripts/types script similar to one in @analytics/core. The script postprocesses the generated types and exports plugin config and plugin type. - Add analytics as dependency so types in types.d.ts can import types - Add 'types' npm command to @analytics/mixpanel - Add 'temp-types' to .gitignore
Thanks for the PR as always 😃 I'm currently stuck on the issue where types can be different between server and client implementations but this isn't supported in typescript (or I can't figure out how to achieve this) More details in thread https://twitter.com/DavidWells/status/1340059740672442368 |
Hi, random stranger here looking for a solution.. for now I'm just going to add my own .d.ts file. Here's an idea: let me import based on the types I want:
For me, I don't need isomorphic code even though I'm using a Next.js app. Having to opt into one or the other is better than having to write my own types. I think the issue is that the library determines the implementation at runtime, but at compile time, I'm not sure Typescript even has a concept of "node", you would at best need to be able to check if a type from the Node lib exists or not, but using undefined types just results in a compile error. |
Background
As a TypeScript user working with the
@analytics/mixpanel
plugin, I want to have the plugin (and primarily the plugin config) covered by TypeScriptAfter #114, adding TypeScript support is trivial as the plugin definition can be reused.
Changes
@analytics/mixpanel
./scripts/types
script similar to one in@analytics/core
.types.d.ts
to export plugin config and plugin interfaces.analytics
as a dependency so types intypes.d.ts
can import the types exposed in Improve typescript support #114'types'
npm command to@analytics/mixpanel
'temp-types'
to.gitignore
Blocked by #114 and #115