nytimes
Suggestion: Add type-safe tracking helpers
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 withtracking.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?
¯\_(ツ)_/¯
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
