Skip to content
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

Merged
merged 8 commits into from
Feb 5, 2024

Conversation

onurtemizkan
Copy link
Collaborator

@onurtemizkan onurtemizkan commented Jan 31, 2024

Adds a custom browserTracingIntegration for @sentry/remix.

This also marks remixRouterInstrumentation as deprecated.

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.

@onurtemizkan onurtemizkan requested a review from mydea January 31, 2024 15:23
@onurtemizkan onurtemizkan force-pushed the onur/remix-browserTracingIntegration branch from fd6503a to 69ea641 Compare January 31, 2024 15:23
@onurtemizkan onurtemizkan changed the title feat(remix): Add remixBrowserTracingIntegration feat(remix): Add browserTracingIntegration Jan 31, 2024
return {
...browserTracingIntegrationInstance,
afterAllSetup(client) {
browserTracingIntegrationInstance.afterAllSetup?.(client);
Copy link
Member

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!

Comment on lines 10 to 16
if (options.startTransactionOnPageLoad === undefined) {
options.startTransactionOnPageLoad = true;
}

if (options.startTransactionOnLocationChange === undefined) {
options.startTransactionOnLocationChange = true;
}
Copy link
Member

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,
Copy link
Member

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) {
Copy link
Member

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

Comment on lines 44 to 45
startTransactionOnPageLoad?: boolean;
startTransactionOnLocationChange?: boolean;
Copy link
Member

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;
Copy link
Member

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...!

@onurtemizkan onurtemizkan force-pushed the onur/remix-browserTracingIntegration branch from 76b1b23 to cd65704 Compare February 1, 2024 11:43
Copy link
Contributor

github-actions bot commented Feb 1, 2024

size-limit report 📦

Path Size
@sentry/browser (incl. Tracing, Replay, Feedback) - Webpack (gzipped) 78.2 KB (0%)
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped) 69.43 KB (0%)
@sentry/browser (incl. Tracing, Replay with Canvas) - Webpack (gzipped) 73.36 KB (0%)
@sentry/browser (incl. Tracing, Replay) - Webpack with treeshaking flags (gzipped) 63.04 KB (0%)
@sentry/browser (incl. Tracing) - Webpack (gzipped) 33.38 KB (0%)
@sentry/browser (incl. browserTracingIntegration) - Webpack (gzipped) 33.25 KB (0%)
@sentry/browser (incl. Feedback) - Webpack (gzipped) 31.33 KB (0%)
@sentry/browser (incl. sendFeedback) - Webpack (gzipped) 31.34 KB (0%)
@sentry/browser - Webpack (gzipped) 22.6 KB (0%)
@sentry/browser (incl. Tracing, Replay, Feedback) - ES6 CDN Bundle (gzipped) 76.17 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped) 67.72 KB (0%)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped) 33.5 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped) 24.66 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed) 213.68 KB (0%)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed) 101.49 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed) 74.01 KB (0%)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped) 36.63 KB (0%)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped) 69.8 KB (0%)
@sentry/react - Webpack (gzipped) 22.63 KB (0%)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped) 86.56 KB (0%)
@sentry/nextjs Client - Webpack (gzipped) 50.8 KB (0%)
@sentry-internal/feedback - Webpack (gzipped) 17.21 KB (0%)

@onurtemizkan onurtemizkan changed the title feat(remix): Add browserTracingIntegration feat(remix): Add custom browserTracingIntegration Feb 1, 2024
@onurtemizkan onurtemizkan force-pushed the onur/remix-browserTracingIntegration branch from 3ab138f to cf07f41 Compare February 1, 2024 12:31
@onurtemizkan
Copy link
Collaborator Author

@mydea, thanks for the review! Pushed the updates. PR is ready for another pass.

@onurtemizkan onurtemizkan marked this pull request as ready for review February 1, 2024 15:57
@onurtemizkan onurtemizkan force-pushed the onur/remix-browserTracingIntegration branch from cf07f41 to 8889d6f Compare February 1, 2024 16:01
export { remixRouterInstrumentation, withSentry } from './client/performance';
export { captureRemixErrorBoundaryError } from './client/errors';
export { browserTracingIntegration } from './client/browserTracingIntegration';
Copy link
Member

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? 😅

Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @Lms24 and/or @lforst you've done something like this for nextjs/sveltekit, can you point in the right direction here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we (unfortunately) export this on both sides, also in SvelteKit (and I believe NextJS). Kinda unfortunate but this is a limitation as long as we don't use sub-path/conditional package exports (or whatever they're called now).

image

Copy link
Member

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..?

Copy link
Member

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

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

@Lms24 Lms24 left a 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!

"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)",
Copy link
Member

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?

Copy link
Collaborator Author

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,
Copy link
Member

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,
Copy link
Member

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?

Copy link
Collaborator Author

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.

Comment on lines 18 to 23
setGlobals({
useEffect: options.useEffect,
useLocation: options.useLocation,
useMatches: options.useMatches,
startTransactionOnLocationChange: options.instrumentNavigation,
});
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Member

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).

Copy link
Collaborator Author

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.

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;
};
}

Copy link
Member

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.

@onurtemizkan onurtemizkan force-pushed the onur/remix-browserTracingIntegration branch from 1d4be11 to 18683ec Compare February 2, 2024 16:17
Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@mydea mydea merged commit baf5f90 into develop Feb 5, 2024
122 checks passed
@mydea mydea deleted the onur/remix-browserTracingIntegration branch February 5, 2024 14:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants