Tap interactions not reported after project setup on IOS

[DavidAmmeraal]

Describe what happened
After following setup instructions described here datadog is reporting views. However, TAP interactions on components do not seem to be working.

We've first tried to get it to work within our existing application, but I've created a minimal repository which also demonstrates the same issue here: https://github.com/DavidAmmeraal/dd-rum-issue

Steps to reproduce the issue:

• Set up new react native project with npx react-native init AwesomeProject
• Install @datadog/dd-sdk-reactnative with yarn add @datadog/mobile-react-native
• Create configuration and call DdSdkReactNative.initialize inside index.js.
• Set verbosity to SdkVerbosity.DEBUG;
• Setup view tracking with @datadog/mobile-react-navigation.
• Add a button with an accessibilityLabel and an onPress handler.
• Run example app inside simulator
• See that views are being reported as intended.
• Press that button.
• No tap is reported to RUM.

Describe what you expected:

• I expect interactions on elements with onPress and an accessibilityLabel to report to RUM.

Additional context

I did a little debugging and see that patched React.createElement inside node_modules/@datadog/mobile-react-native/src/rum/instrumentation/DdRumUserInteractionTracking.tsx is never being called.

I also figured out that the call to const jsxRuntime = getJsxRuntime(); in that same file is failing (nothing is done with the error however).

• Version of the SDK: "@datadog/mobile-react-native": "^1.1.4"

package.json

{
 "name": "AwesomeTSProject",
 "version": "0.0.1",
 "private": true,
 "scripts": {
 "android": "react-native run-android",
 "ios": "react-native run-ios",
 "start": "react-native start",
 "test": "jest",
 "lint": "eslint . --ext .js,.jsx,.ts,.tsx"
 },
 "dependencies": {
 "@datadog/mobile-react-native": "^1.1.4",
 "@datadog/mobile-react-navigation": "^1.1.4",
 "@react-navigation/native": "^6.0.16",
 "@react-navigation/native-stack": "^6.9.4",
 "react": "18.1.0",
 "react-native": "0.70.6",
 "react-native-config": "^1.4.11",
 "react-native-safe-area-context": "^4.4.1",
 "react-native-screens": "^3.18.2"
 },
 "devDependencies": {
 "@babel/core": "^7.12.9",
 "@babel/runtime": "^7.12.5",
 "@react-native-community/eslint-config": "^2.0.0",
 "@tsconfig/react-native": "^2.0.2",
 "@types/jest": "^26.0.23",
 "@types/react": "^18.0.21",
 "@types/react-native": "^0.70.6",
 "@types/react-test-renderer": "^18.0.0",
 "@typescript-eslint/eslint-plugin": "^5.37.0",
 "@typescript-eslint/parser": "^5.37.0",
 "babel-jest": "^26.6.3",
 "eslint": "^7.32.0",
 "jest": "^26.6.3",
 "metro-react-native-babel-preset": "0.72.3",
 "react-test-renderer": "18.1.0",
 "typescript": "^4.8.3"
 },
 "jest": {
 "preset": "react-native",
 "moduleFileExtensions": [
 "ts",
 "tsx",
 "js",
 "jsx",
 "json",
 "node"
 ]
 }
}

Podfile and Podfile.lock

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform :ios, '12.4'
install! 'cocoapods', :deterministic_uuids => false

target 'AwesomeTSProject' do
 config = use_native_modules!

 # Flags change depending on the env values.
 flags = get_default_flags()

 use_react_native!(
 :path => config[:reactNativePath],
 # Hermes is now enabled by default. Disable by setting this flag to false.
 # Upcoming versions of React Native may rely on get_default_flags(), but
 # we make it explicit here to aid in the React Native upgrade process.
 :hermes_enabled => true,
 :fabric_enabled => flags[:fabric_enabled],
 # Enables Flipper.
 #
 # Note that if you have use_frameworks! enabled, Flipper will not work and
 # you should disable the next line.
 :flipper_configuration => FlipperConfiguration.enabled,
 # An absolute path to your application root.
 :app_path => "#{Pod::Config.instance.installation_root}/.."
 )

 target 'AwesomeTSProjectTests' do
 inherit! :complete
 # Pods for testing
 end

 post_install do |installer|
 react_native_post_install(
 installer,
 # Set `mac_catalyst_enabled` to `true` in order to apply patches
 # necessary for Mac Catalyst builds
 :mac_catalyst_enabled => false
 )
 __apply_Xcode_12_5_M1_post_install_workaround(installer)
 end
end

[louiszawadzki]

Hi @DavidAmmeraal, thanks for reaching out and the research that you did!

Indeed that getJSXRuntime crashing is the cause of the issue here. It is because of a modification introduced in our version 1.1.4 to support React versions below 16.14.0.

Short term solution: Version 1.1.3 of @datadog/mobile-react-native works on your sample app (thank you so much for providing one!), and should work on your app. Let me know if that's not the case.
Version 1.1.4 only contains the fix for older versions of React, so you won't be missing any feature.

I'm going to continue investigating to find a fix that works for all versions of React, and will update you once it is released :)

[DavidAmmeraal]

@louiszawadzki thanks for your reply!

I've downgraded to 1.1.3, however it still didn't work as expected. I see react/jsx-runtime is now being included correctly. However the patched function is not being called when rendering the app.

I believe it's because I'm not awaiting DdSdkReactNative.initialize(datadogConfig); in index.js, and the UI is already rendered before jsxRuntime.jsx has been patched. However, metro doesn't like me awaiting that promise (either through await or .then() inside top-level index.js, so the instructions as described here https://github.com/DataDog/dd-sdk-reactnative/blob/develop/docs/troubleshooting.md#with-ddsdkreactnativeinitialize, and on https://github.com/DataDog/dd-sdk-reactnative#initialize-the-library-with-application-context are slightly confusing, and could possibly do with some extra explanation.

I worked around it by initializing datadog in top level component and rendering the children once the promise settles.

I guess the provider in 1.2.0-beta1 will resolve this issue.

[louiszawadzki]

Hi @DavidAmmeraal,

Indeed with the current implementation there is a need for one re-render to happen for the patch to be active.

This will indeed be solved with the new DatadogProvider approach as we're able to do the auto-instrumentation of interaction before the first render happens.

I also apologize for the misleading instructions with the use of await outside of a function, I'll make an edit to code snippets to avoid this situation :)

[louiszawadzki]

Hi @DavidAmmeraal ,

I think that you found the solution to your issue :)
As it's not been active for a while I'm going to close it, feel free to reopen it if this is not the case!