Hacker News new | ask | show | jobs
by rezz 2178 days 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?

1 comments

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.

Couldn't the `TouchableOpacity` component somehow be overwritten by the Heap HOC?
I'm not sure I totally understand your question. Could you elaborate?
I think they're suggesting something hooking into webpack to override all imports of TouchableOpacity with your version. Or you could even monkey patch it in at runtime.
I was referring to monkey-patching, yes, just overwrite that function.