React native tracker probably shouldn't have been published yet

[pfulop]

Describe the bug
Seems like there's a 4.3.1 version of @snowplow/react-native-tracker published on npm. This is still pointing to the old documentation but what's worse it doesn't seem to be functional. While this version should be JS only, it seems to depended on some native package that causes error:

Error initializing tracker [Error: Native module not found]

Inspecting this it seems to be due to react-native-get-random-values. I think what's happening here is that the native dependencies of this package are not installed (at least not with expo, but I doubt it works with pure rn project), due to this being just a js library now. I assume this will be listed as a dependencies that consumers need to install on their own, but for now, it's hard to understand what's going on.

To Reproduce
Install @snowplow/react-native-tracker

Expected behavior
React native tracker should work.

Smartphone (please complete the following information):

• Device: Android/iOS
• OS: Any
• Browser none
• Version irrelevant

[matus-tomlein]

Hi @pfulop, thanks for reporting this.

The react-native-get-random-values is listed as a dependency of the tracker and that should be provided in Expo Go, but might require running pod install under the dev build.

I have just tried to create a new Expo app and install the tracker and use it, but I don't see the same error as you stated.

Could you try running pod install whether that resolves the issue under iOS? Do you see the same on Android?

[pfulop]

Interesting, I do see it as a dependency in the expo project. But looking at our yarn.lock, I see it only as a dependency of @snowplow/react-native-tracker. We're fully using expo-cli which doesn't let you install pods directly, instead, it uses a prebuild step.

Could you maybe see if the react-native-get-random-values in yarn.lock is a dependency of something else as well? Also, are you running it in Expo-go? I can imagine it works there since they bring react-native-get-random-values through some random/crypto libs.

[valeriobelli]

Hello folks 👋🏽
I might be wrong, but shouldn't @react-native-async-storage/async-storage and react-native-get-random-values be defined as peerDependencies?

As far as I can see, consumers of @snowplow/react-native-tracker who are not using Expo must explicitly install those two dependencies to benefit from the auto-linking feature.

[valeriobelli]

After having reasoned a bit on it, I have an absurd idea. What if the React Native tracker accepts a storage interface in newTracker? This would allow consumers to define other storage instead of defaulting to AsyncStorage. For example, MMKV is a popular alternative in the React Native community that could be used alternatively.

[matus-tomlein]

Thanks for the suggestions @valeriobelli! Have moved the storage question into a separate task.

For this issue I moved the react-native-get-random-values dependency to peer dependencies in #1414

[valeriobelli]

Thanks for the answer, @matus-tomlein. This is super. 🚀

I might be mistaken, but as far as I can see, I think a similar topic that applies to Async Storage can be applied to react-native-get-random-values. As far as I know, react-native-quick-crypto is a pretty good alternative to what react-native-get-random-values tries to do, which is polyfilling.

For example, in our codebase, we are already using react-native-quick-crypto for polyfilling getRandomValues required by @growthbook/growthbook and uuid. However, this is just an example; I don't want to bend your decision and architecture for our use case. 🤓 Perhaps our use case might be reflected in other products, too.