Skip to content
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

Open
wants to merge 15 commits into
base: master
Choose a base branch
from
Open

Conversation

JuroOravec
Copy link

Background

As a TypeScript user working with the @analytics/mixpanel plugin, I want to have the plugin (and primarily the plugin config) covered by TypeScript

After #114, adding TypeScript support is trivial as the plugin definition can be reused.

Changes

  • Add type annotations to types and functions in @analytics/mixpanel
  • Add ./scripts/types script similar to one in @analytics/core.
    • The script post-processes the generated types.d.ts to export plugin config and plugin interfaces.
  • Add analytics as a dependency so types in types.d.ts can import the types exposed in Improve typescript support #114
  • Add 'types' npm command to @analytics/mixpanel
  • Add 'temp-types' to .gitignore

Blocked by #114 and #115

Juro Oravec added 15 commits November 14, 2020 17:42
- 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'
…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
- 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
@DavidWells
Copy link
Owner

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

@mattcasey
Copy link

mattcasey commented Jan 12, 2023

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:

import mixpanelBrowserPlugin from '@analytics/mixpanel/browser'; // browser client
import mixpanelServerPlugin from '@analytics/mixpanel/node'; // node client

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants