React-Native Feedback Thread

For engineers Tracking SDKs
1

Hi All,

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.
1 Like
2

@tfinkel, @kinney, @Alexandre_Rayes, @postfactum, @VanHoutte - you’ve all asked about or suggested that you’re using react-native in some capacity. For those of you that are using/can now use this tracker, it would be really great to hear back from you!

@aditya - you previously mentioned you’d like to use it but need the mobile context. It’s in there now so if you’re in a position to give it a go, it would be great to hear back on the results!

3 Likes
3

@Colm we’ve got it up and running! I can’t add much from an engineer’s perspective but the events are filtering through nicely and it seemed fairly straightforward to implement.

We ran into a couple of quirks / questions:

  • it doesn’t seem like trackStructEvent will allow null/undefined on se_property or se_value which should be optional
  • it doesn’t seem like device info is flowing through correctly… os_name is always Mac OS X and dvce_type is always Computer

Not sure if this is an implementation issue on our end or as part of the library. Thanks!

2 Likes
4

As this gets enriched from the useragent what should this be out of interest? It seems like in order to get something meaningful here we might need to “trick” the user agent enrichment(s) by constructing a user agent string that includes the OS information / version.

1 Like
5

@tfinkel that’s awesome, great to hear.

it doesn’t seem like trackStructEvent will allow null/undefined on se_property or se_value which should be optional

So, this is fixed in the latest version. Do note if you’re upgrading that the initialize method now takes an extra argument RNSnowplowTracker.initialize('test-endpoint-url', 'post', 'https', 'namespace', 'app-id', {});

it doesn’t seem like device info is flowing through correctly… os_name is always Mac OS X and dvce_type is always Computer

This is unexpected since as @mike said these come from the useragent field - we’ll take a look at how that’s set. However, the latest version provides a better means of device identification via the mobile context, which is always enabled (for now - we’ll probably look to make it configurable in a future release). I tested that on my own phone and it worked (android, I haven’t got an iOS device handy to test on so let me know if there are issues there).

Best,

6

@tfinkel that’s awesome, great to hear.

it doesn’t seem like trackStructEvent will allow null/undefined on se_property or se_value which should be optional

So, this is fixed in the latest version. Do note if you’re upgrading that the initialize method now takes an extra argument RNSnowplowTracker.initialize('test-endpoint-url', 'post', 'https', 'namespace', 'app-id', {});

it doesn’t seem like device info is flowing through correctly… os_name is always Mac OS X and dvce_type is always Computer

This is unexpected since as @mike said these come from the useragent field - we’ll take a look at how that’s set. However, the latest version provides a better means of device identification via the mobile context, which is always enabled (for now - we’ll probably look to make it configurable in a future release).

7

awesme @Colm. I will feedback to my team about this!

1 Like
8

An update/FYI for those interested in the autoScreenView feature.

I’ve had some interesting feedback from an experienced RN developer about what the considerations are here. It seems that there are two commonly used libraries for handling screen transitions: react-navigation and react-native-navigation.

One of these handles things in JS, and the other leans on native methods. The current instrumentation of auto screen views just enables the native trackers’ current autotracking capability, so it may well work for the one that handles navigation using native methods (but that’s not a guarantee).

So, I’d love to hear back from anyone who has tried this, what the results were, and whether they’re using one of these two libraries.

1 Like
9

Hi @Colm — I work with @tfinkel and @kinney. Just wanted to provide some feedback.

  • We’ve relied exclusively on the trackStructuredEvent method thus far.
  • We hit one snag: the numeric value property does not appear to be optional, despite the documentation. I submitted a GitHub issue for this.)
  • Regarding auto-tracking of screen views, the codebase we’re working on uses React Navigation, which is fully JavaScript-based, so this likely won’t work with autoScreenView. But that’s fine; I see it as the clients’ responsibility to invoke trackScreenViewEvent as needed, and it should be straightforward for us to hook Snowplow up to React Navigation.
  • One feature we would love to see is TypeScript support! Our codebase makes heavy use of TypeScript, and right now, we have a custom .d.ts type declaration file for use with @snowplow/react-native-tracker. We would be more than happy to contribute this to your codebase.
2 Likes
10

Thanks @mmikolayatq, that’s great feedback!

We hit one snag: the numeric value property does not appear to be optional, despite the documentation. I submitted a GitHub issue for this.)

Ah - so I think I see what’s happening there. It is nullable but not optional - I plan on going through design considerations with our product team on how to treat this kind of parameter. Because RN doesn’t let you make explicit arguments optional, we might consider changing all methods to take a JSON for any optional arguments. I’m undecided on what the smoother/more intuitive user experience would be atm but it’s something worth mulling over. Thanks for raising the issue! I agree the readme doesn’t make this clear.

Regarding auto-tracking of screen views, the codebase we’re working on uses React Navigation, which is fully JavaScript-based, so this likely won’t work with autoScreenView . But that’s fine; I see it as the clients’ responsibility to invoke trackScreenViewEvent as needed, and it should be straightforward for us to hook Snowplow up to React Navigation.

Yes and I think even for a full v1 this is probably how it’ll be done - thanks for the input!

One feature we would love to see is TypeScript support! Our codebase makes heavy use of TypeScript,

Funnily enough this has been raised by someone else as well and I’m definitely on board with it. The core module of our javascript tracker does this (this is an npm module which isn’t intended for general use but is imported into some of our other tracking libraries).

we have a custom .d.ts type declaration file for use with @snowplow/react-native-tracker . We would be more than happy to contribute this to your codebase.

Yes I think we’d be happy for this kind of contribution if you’re willing to share!

I don’t know atm when the next batch of work on react native will be scheduled for, but once that happens we can definitely review it and see if we can get it into the next release. (We’re hopeful of getting to it before the end of the year, we just have a little bit of uncertainty in timing as we’re onboarding new team members and it’s hard to say how we’ll end up allocating work until they’re properly up and running).

11

Any updates on the TS support?

12

Hi @Praveen_Sahu,

No, we’d like to add it, but it’s not found its way into a release yet (the last release needed quite a lot of testing).

Still open to a contribution, if someone wanted to provide one - otherwise hopefully it can fit into next release - but I have no guidance on when that might be atm.

13

Hi team,
How can we dev test all the events with RN tracker? Chrome extensions in chrome debugger dont seem to be working.

14

Hey @Pulkit_Sharma

We often use Snowplow Micro or Snowplow Mini to test mobile applications are sending the expected events.

1 Like