Using Babel transforms to inject analytics code at build time(heap.io)
heap.io
Using Babel transforms to inject analytics code at build time
https://heap.io/blog/engineering/how-we-leveraged-asts-and-babel-to-capture-everything-on-react-native
14 comments
FYI, the layout is unreadable on mobile Firefox (on Android fwiw; looks fine in Chrome).
Author here! I worked on our babel plugin for React Native autocapture from day one. It's been a pretty interesting project. Would be happy to answer any questions you have!
The article seems to end before solving the original problem. You start out with a call to `analytics.track` and seem to just forget about it. Do you mind sharing examples of how to disambiguate the sender / event args in `captureTouchablePress` into something meaningful?
Good point, we didn’t really get into that part of the story.
At Heap, we have a concept of a “virtual event”, in which there’s a raw event data set, and then you (the Heap customer) would “define” events on this raw data through our UI. The resulting data set is what you’d normally get from traditional `analytics.track` code, except it would be retroactive to the point when you installed Heap, you can change/delete/create events (without losing the underlying data), and you wouldn’t have actually written any additional tracking code.
We have some material on virtual events on https://heap.io/product/virtual-events, and the code that extracts the raw events from these interactions can be found at https://github.com/heap/react-native-heap/blob/c2dae7ef2442a... (the function our babel plugin hooks into) and https://github.com/heap/react-native-heap/blob/c2dae7ef2442a... (the function that creates most of the raw event we send to Heap)
At Heap, we have a concept of a “virtual event”, in which there’s a raw event data set, and then you (the Heap customer) would “define” events on this raw data through our UI. The resulting data set is what you’d normally get from traditional `analytics.track` code, except it would be retroactive to the point when you installed Heap, you can change/delete/create events (without losing the underlying data), and you wouldn’t have actually written any additional tracking code.
We have some material on virtual events on https://heap.io/product/virtual-events, and the code that extracts the raw events from these interactions can be found at https://github.com/heap/react-native-heap/blob/c2dae7ef2442a... (the function our babel plugin hooks into) and https://github.com/heap/react-native-heap/blob/c2dae7ef2442a... (the function that creates most of the raw event we send to Heap)
First of all excellent write up, thanks for putting in the time.
Apologies if you mentioned this in the article and I missed it, but what advantages does an approach like this have over creating a HOC?
Apologies if you mentioned this in the article and I missed it, but what advantages does an approach like this have over creating a HOC?
Thanks for the question! There were a few other alternative approaches we considered at the time, but didn't get into those in this post.
If I understand correctly, you mean something like the Heap library providing a `HeapTouchableOpacity` HOC that wraps the React Native `TouchableOpacity`. IIRC we actually considered something like this when brainstorming different approaches. I think one of the biggest issues with this approach is that all `TouchableOpacity`s in an app must be `HeapTouchableOpacity`s.
This might seem acceptable at first, but there are a lot of other components that use `TouchableOpacity` under the hood (e.g. the React Native `Button`, and other components in libraries like Native Base), and these would also need to use `HeapTouchableOpacity`. On top of that, if you already have a React Native app that you want to implement Heap on, you'd need to change all of your `TouchableOpacity`s to `HeapTouchableOpacity`s. We believed this drifted too far from our philosophy around autocapture, and decided against this.
Hope this answers your question! Let me know if you have any follow-up Qs.
If I understand correctly, you mean something like the Heap library providing a `HeapTouchableOpacity` HOC that wraps the React Native `TouchableOpacity`. IIRC we actually considered something like this when brainstorming different approaches. I think one of the biggest issues with this approach is that all `TouchableOpacity`s in an app must be `HeapTouchableOpacity`s.
This might seem acceptable at first, but there are a lot of other components that use `TouchableOpacity` under the hood (e.g. the React Native `Button`, and other components in libraries like Native Base), and these would also need to use `HeapTouchableOpacity`. On top of that, if you already have a React Native app that you want to implement Heap on, you'd need to change all of your `TouchableOpacity`s to `HeapTouchableOpacity`s. We believed this drifted too far from our philosophy around autocapture, and decided against this.
Hope this answers your question! Let me know if you have any follow-up Qs.
Couldn't the `TouchableOpacity` component somehow be overwritten by the Heap HOC?
I'm not sure I totally understand your question. Could you elaborate?
More info on the visitor pattern, which was originally published by the Gang of Four:
https://en.wikipedia.org/wiki/Visitor_pattern
Rarely seen in its pure form in the wild, but it's vastly useful, and surprisingly versatile, when you need it.
https://en.wikipedia.org/wiki/Visitor_pattern
Rarely seen in its pure form in the wild, but it's vastly useful, and surprisingly versatile, when you need it.
Never realized this had a name. Very cool.