Using Babel transforms to inject analytics code at build time

Using Babel transforms to inject analytics code at build time(heap.io)

46 points by drob 5 years ago | 14 comments

stblack 5 years ago |

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.

whalesalad 5 years ago | |

Never realized this had a name. Very cool.

uhoh-itsmaciek 5 years ago |

FYI, the layout is unreadable on mobile Firefox (on Android fwiw; looks fine in Chrome).

drob 5 years ago | |

Fixed. Thank you again for flagging!

drob 5 years ago | |

Ah. Yup, it is. Thank you for flagging. Will fix this.

jmtaber129 5 years ago |

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!

mikewhy 5 years ago | |

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?

jmtaber129 5 years ago | | |

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)

rezz 5 years ago | |

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?

jmtaber129 5 years ago | | |

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.