Suggestion: Add type-safe tracking helpers

[garbles]

Hello! We're using this library to integrate tracking into our React front-end, but we use TypeScript and trying to type the track function is a nightmare. The type definitions (@types/react-tracking) do not work as expected and we've resorted to wrapping track (typed as any) in several other functions to get some type safety. What we ended up with were:

• TrackingProvider: Component to wrap the entire application
• withTracking: HOF to augment component props with tracking.trackEvents
• trackOnMount: HOF to dispatch a tracking event on mount (only accepts a function with props so that it works similar to how Apollo populates query arguments with prop values)
• track: Method decorator (also only accepts a function with props)

Are you interested in moving toward a more static interface like this? Where one function can only do one thing? It would make integrating with TypeScript projects a lot easier. Of course, NYTimes may not have this problem though. LMK! 🙂

One more note: Introducing TrackingProvider might be necessary anyway with the new context API?
¯\_(ツ)_/¯

[tizmagik]

Hey @garbles thanks for posting this issue and bringing it to my attention. We do not (currently) use TypeScript at NYT, so we haven't felt this pain, but I could definitely see how this is problematic for TypeScript based projects.

Please correct me if I'm wrong here, but I think the interface you described there is generally how it is now, with the exception of the track method -- that method can be called with a function or an object literal -- this is important to maintain because we do not want the additional function overhead if it can be avoided.

Would you be interested/would it make sense to update the @types/react-tracking? I definitely do not want the story around type safety while using react-tracking to be a deterrent to using the library so I'm open to talking through a good solution here 😄

RE: Introducing TrackingProvider yes, that may be necessary and depends on where we end up with #67