feat(instrumentation-react-native-navigation): Adding new instrumentation library to track navigation changes for React Native apps #2359
Conversation
|
|
facostaembrace
changed the title
facostaembrace
force-pushed
the
instrumentation-react-native-navigation
branch
from
7899a94
to
42ac15b
Compare
facostaembrace
changed the title
facostaembrace
force-pushed
the
instrumentation-react-native-navigation
branch
from
42ac15b
to
cc3c154
Compare
|
Fyi: still pending to submit the Instrumentation request that introduces this initiative. |
facostaembrace
force-pushed
the
instrumentation-react-native-navigation
branch
from
cc3c154
to
f71bc35
Compare
…ion library to track navigation for React Native apps
… for attributes + cleaning up tests
…adding comments + renaming spanCreator file
facostaembrace
force-pushed
the
instrumentation-react-native-navigation
branch
from
31f5acc
to
eea8205
Compare
There was a problem hiding this comment.
We now have provided guidance for new instrumentations getting added to this repo. Ideally this could be hosted elsewhere, but we will need at minimum 2 codeowners before we can review.
|
Hi @JamieDanielson . Thanks for taking a look! Yes, I read that document before, but I still have a question about it. Should I add myself (and somebody else) as component owner? Or should this code owner be somebody already accepted by the community? |
It is okay if you are the codeowner along with another person who will help review issues, maintain the instrumentation, etc. Hopefully you will become more a part of the community over time 😃 but it is not necessary to be a JS approver, for example. A main concern at the moment is that we are light on bandwidth for the amount of instrumentations being hosted here, so we want to ensure that new things being added have ownership by someone willing to maintain them. Please add yourself and another codeowner to |
…ct-native-navigation
JamieDanielson
dismissed
their stale review
Dismissing stale request for changes, PR is ready for review
package-lock.json
Outdated
There was a problem hiding this comment.
was curious about the large diff here, is it all just coming from devDependencies added in plugins/node/instrumentation-react-native-navigation/package.json?
There was a problem hiding this comment.
it seems like that, it's was all autogenerated. Started by a fresh state (by just running npm ci at the beginning of the implementation) + adding the devDependencies for the @opentelemenetry/instrumentation-react-native-navigation (and running the proper npm i) results in this big diff here
| }), []); | ||
|
|
||
| return ( | ||
| <NavigationTracker ref={navigationRef} provider={provider}> |
There was a problem hiding this comment.
I seemed to have hit a typing error when following this example:
"NavigationContainerRefWithCurrent<RootParamList> is not assignable to type LegacyRef<INavigationContainer> | undefined"
I was able to ignore and it seemed to function fine but wasn't sure if that was a known issue is something particular to my setup?
| } | ||
| ``` | ||
|
|
||
| If you dig into the attributes, `view.launch` refers to the moment the app is launched. It will be `true` only the first time the app mounts. Changing the status between background/foreground won't modify this attribute. For this case the `view.state.end` is used, and it can contain two possible values: `active` and `background`. |
There was a problem hiding this comment.
there is technically a third "inactive" state that's possible on iOS which may be worth calling out here, see: https://reactnative.dev/docs/appstate#app-states
| import { useMemo } from 'react'; | ||
|
|
||
| const consoleStub = { | ||
| // eslint-disable-next-line @typescript-eslint/no-unused-vars |
There was a problem hiding this comment.
curious if other instrumentations require similar configurable logging, may be useful to pull out into a resuable helper
There was a problem hiding this comment.
I think it's a great idea, I would vote for revisit this initiative after this PR is merged to try to isolate this as a test helper
| span.current.setAttributes({ | ||
| // it should create the first span knowing there is not a previous view | ||
| [ATTRIBUTES.initialView]: !!isLaunch, | ||
| // it should set the view name in case it's useful have this as attr |
There was a problem hiding this comment.
| // it should set the view name in case it's useful have this as attr | |
| // it should set the view name in case it's useful to have this as an attr |
There was a problem hiding this comment.
seems like this file was accidentally updated
There was a problem hiding this comment.
true. reverting. thanks for catching this
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2359 +/- ##
==========================================
+ Coverage 90.85% 90.91% +0.05%
==========================================
Files 159 166 +7
Lines 7853 8022 +169
Branches 1622 1657 +35
==========================================
+ Hits 7135 7293 +158
- Misses 718 729 +11
|
Which problem is this PR solving?
A couple of months ago, my team (Embrace) and I were looking for an instrumentation library that creates telemetry data for React Native applications. However, we noticed there was nothing available that adhered to open source standards. We also noticed people in Stack Overflow was asking about something similar.
This instrumentation library exposes two components that can be implemented at the root of React Native applications to create telemetry data that tracks navigation changes for the most popular navigation approaches in this environment.
Instrumentation request here.
#1089
Short description of the changes
<NativeNavigationTracker />that creates spans and track navigation changes forwix/react-native-navigationlibrary, and<NavigationTracker />that is meant to be used when the application handles the navigation using@react-navigation/nativeorexpo-router.