-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(remix): Add custom browserTracingIntegration
#10442
Conversation
fd6503a
to
69ea641
Compare
remixBrowserTracingIntegration
browserTracingIntegration
return { | ||
...browserTracingIntegrationInstance, | ||
afterAllSetup(client) { | ||
browserTracingIntegrationInstance.afterAllSetup?.(client); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on latest (we changed recently) you should not need ?.
as this should be properly typed!
if (options.startTransactionOnPageLoad === undefined) { | ||
options.startTransactionOnPageLoad = true; | ||
} | ||
|
||
if (options.startTransactionOnLocationChange === undefined) { | ||
options.startTransactionOnLocationChange = true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need this? Instead we should check instrumentPageLoad
and instrumentNavigation
here!
useEffect: options.useEffect, | ||
useLocation: options.useLocation, | ||
useMatches: options.useMatches, | ||
startTransactionOnLocationChange: options.startTransactionOnLocationChange, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use options.instrumentNavigation
here instead?
afterAllSetup(client) { | ||
browserTracingIntegrationInstance.afterAllSetup?.(client); | ||
|
||
if (options.startTransactionOnPageLoad) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use options.instrumentPageLoad
here instead
startTransactionOnPageLoad?: boolean; | ||
startTransactionOnLocationChange?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't need this here and should instead rely on the new instrumentXXX
options :)
'routing.instrumentation': 'remix-router', | ||
} as const; | ||
|
||
let activeRootSpan: Span | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we actually need the active root span here? 🤔 ideally we can get rid of this global/module state...!
76b1b23
to
cd65704
Compare
size-limit report 📦
|
browserTracingIntegration
browserTracingIntegration
3ab138f
to
cf07f41
Compare
@mydea, thanks for the review! Pushed the updates. PR is ready for another pass. |
cf07f41
to
8889d6f
Compare
export { remixRouterInstrumentation, withSentry } from './client/performance'; | ||
export { captureRemixErrorBoundaryError } from './client/errors'; | ||
export { browserTracingIntegration } from './client/browserTracingIntegration'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be exported from client, not server, I guess? 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually it is exported from client, but we should not export it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're sadly forced to export all client-side exports from the server-side as well, we previously had issues with unresolved imports and/or broken typings when we didn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would not be better then to export the shim integrations as we do for the bundles - we already have that code for the bundles anyhow, and it's def. safer in regards to avoiding accidentally including browser-specific stuff..? that also takes care of warning if it is used etc..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've had these discussions before and current status quo was to be mindful of where users are add the integration. Fwiw, the only common use case would be replay anyway. Only Remix requires users to additionally manually add BrowserTracing
(something we should change long term btw).
related
- Attempted import error: 'Replay' is not exported from '@sentry/nextjs' (imported as 'Sentry'). #9796
"captureRemixServerException" is not exported by "node_modules/@sentry/remix/esm/index.client.js"
#9594
I guess shimming is not the end of the world but the problem is that we need to figure out where we draw the line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, i don't think shimming has high prio and we might solve this with the package exports anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 ok, so the outcome is we export browser tracing & replay in both client and server?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just had a couple of questions but looks good generally!
packages/remix/package.json
Outdated
"test:integration:ci": "run-s test:integration:clean test:integration:prepare test:integration:client:ci test:integration:server", | ||
"test:integration:prepare": "(cd test/integration && yarn)", | ||
"test:integration:prepare": "(cd test/integration && yarn install --force)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: why do we need the --force
flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, we don't need. It's a leftover from when I'd been yarn linking / unlinking a lot to test this. Removing.
useEffect, | ||
useLocation, | ||
useMatches, | ||
startTransactionOnLocationChange, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: Can we rename this to instrumentNavigation
to align more with the new API? (not sure if we'd break something but looks like this is a new function)
useLocation, | ||
useMatches, | ||
startTransactionOnLocationChange, | ||
customStartTransaction, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is still there for compatibility with the old routing instrumentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can remove this while removing the old instrumentation completely.
setGlobals({ | ||
useEffect: options.useEffect, | ||
useLocation: options.useLocation, | ||
useMatches: options.useMatches, | ||
startTransactionOnLocationChange: options.instrumentNavigation, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To confirm: We can't get rid of setting the hooks globally because we can't really pass them into withSentry
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we can pass them into withSentry
. We can try switching to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @AbhiPrasad / @mydea wdyt would this be a good change?
My PoV:
- cleaner as we don't need to set anything globally
- but requires more changes for users when migrating (also more wizard changes for us).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remembered why, this instrumentation is very similar to what we have for react-router 6. So it was for consistency.
sentry-javascript/packages/react/src/reactrouterv6.tsx
Lines 44 to 80 in cc0fcb8
export function reactRouterV6Instrumentation( | |
useEffect: UseEffect, | |
useLocation: UseLocation, | |
useNavigationType: UseNavigationType, | |
createRoutesFromChildren: CreateRoutesFromChildren, | |
matchRoutes: MatchRoutes, | |
stripBasename?: boolean, | |
) { | |
return ( | |
customStartTransaction: (context: TransactionContext) => Transaction | undefined, | |
startTransactionOnPageLoad = true, | |
startTransactionOnLocationChange = true, | |
): void => { | |
const initPathName = WINDOW && WINDOW.location && WINDOW.location.pathname; | |
if (startTransactionOnPageLoad && initPathName) { | |
activeTransaction = customStartTransaction({ | |
name: initPathName, | |
op: 'pageload', | |
origin: 'auto.pageload.react.reactrouterv6', | |
tags: SENTRY_TAGS, | |
metadata: { | |
source: 'url', | |
}, | |
}); | |
} | |
_useEffect = useEffect; | |
_useLocation = useLocation; | |
_useNavigationType = useNavigationType; | |
_matchRoutes = matchRoutes; | |
_createRoutesFromChildren = createRoutesFromChildren; | |
_stripBasename = stripBasename || false; | |
_customStartTransaction = customStartTransaction; | |
_startTransactionOnLocationChange = startTransactionOnLocationChange; | |
}; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh I see, good point. apart from getting rid of the globals there's not really much value from a user perspective. So let's leave it as is.
1d4be11
to
18683ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Adds a custom
browserTracingIntegration
for@sentry/remix
.This also marks
remixRouterInstrumentation
asdeprecated
.It's still functional, and the logic checks the existence of globally defined
_customStartTransaction
to decide how to behave.Added another integration test application for now using Remix v2 and the new
browserTracingIntegration
until we switch to it completely.