We’ve spent a bit of time getting the new react-native tracker project into shape, and to a point where we have now published a usable alpha version which includes some of the most in-demand features (screen views, custom events and contexts, the mobile context).
There seems to be a lot of interest in the react-native tracker, and already I’ve had several people get in touch about instrumenting it, which is really encouraging. I’m very optimistic of the react-native tracker’s potential - we’re still in quite early stages but it’s already got a featureset that enables a tracking design that accommodates most use cases - provided you’re happy to use custom events and entities where the current iteration of the react-native tracker doesn’t provide what’s out-of-the-box for the mobile-native trackers.
This sprint of work focused on resolving issues with implementation, fixing a few bugs, and adding the mobile context and screen-view tracking. These are all in the current alpha version (
alpha.13), which is tagged as
latest in NPM.
I’m opening this thread in hopes that we can capitalise on the momentum and interest in the tracker, and gather feedback and ideas in one place. We’re really keen to hear back from the community to understand what features are working as expected, whether there are any awkward/confusing results, and what the pain points are to using the tracker.
It would also be really useful for us to hear suggestions from those in the community with experience in building react-native apps, wherever there’s an improvement that could be made or an approach that better suits the react-native environment.
There’s likely to be some breaking changes between this alpha version and the final v1 - but the hope is that handling this is less painful than manually bridging the native trackers!
We are also open to code contributions - feel free to bounce ideas around in this thread if you’re keen to contribute, or open a new thread to check with us if the approach fits with the direction of the tracker.
What to include in a reply to this thread
- Details of what methods you’ve used
- Report back what results were as expected and details of anything unexpected
- Suggestions or ideas on how we might go about refactoring parts of the code to be better suited to react-native (ideally including what the benfits/pitfalls are)
- If instrumenting the tracker to meet your tracking needs has required any workarounds/instrumenting any logic yourself, please share the details.
- If you want to make a contribution, but want to validate the idea with other users of the tracker, feel free to use this thread! (but it’s worth also opening a new thread or github issue before starting, so we can make sure the approach will fit our plans for the tracker).
One area we’re particularly interested in at the moment is auto-tracking of screen views. Currently, this
initialize option will simply activate the iOS/Android-native autotracking - which depends on main activity/view controller based transitions that react-native may not actually utilise. Sharing thoughts on how react-native handles screen transitions, and the circumstances under which the current instrumentation of auto-tracking works/doesn’t work would be very helpful!
When to open a new thread instead of replying to this one
- If you need advice on setting up the tracker, create a new topic.
- If you think you’ve spotted a bug, but aren’t sure/want to confirm before opening a GH issue, create a new topic.