Uh oh!
There was an error while loading. Please reload this page.
feat(browser): Add mode option for the browser session integration - #18997
Conversation
6dae52a to
85aa5daComparesize-limit report 📦
|
c45eae4 to
452d0c4Compare| * | ||
| * @default 'navigation' | ||
| */ | ||
| mode?: 'single' | 'navigation'; |
There was a problem hiding this comment.
I am not 100% sure about the naming here, as it's only clear when reading the JS doc. A suggestion:
sessionMode: 'navigation'|'only-pageload'Hm, now that I think more about it, it's probably fine because this is an option in the browserSessionIntegration and it should be clear that this is about the session. So the naming would actually work already (just leaving this to share my thoughts).
There was a problem hiding this comment.
uuuuuuh, I actually like only-pageload. However, it seems too technical correct - it could be that "only-pageload" implies that it doesn't track the session further 🤔
@Lms24 wdyt? To get a third opinion here :)
There was a problem hiding this comment.
hmm yeah, "only-pageload" to me also implies something like "we only track sessions for the pageload and stop afterwards".
Let's think about this, also from a perspective of potentially adding a third mode for persisting the id in sessionStorage in the future. So mentally, it should correlate to "short -> medium -> long".
How about:
lifecycle: 'route' | 'page' | 'tab'lifecycle: 'navigation' | 'pageload' | 'tab'
1 has the advantage that it's very descriptive, but confusion could come from "page". I think this is minimal and also kinda works anyway because it's primarily relevant for Single Page applications".
2 is a bit more technical but correlates well with established Sentry terms.
I think with the proper JSDoc (which is already there xD), both would work well. Especially if we pair these with lifecycle since this more directly implies session life time than "mode" IMHO. Fully realizing I said other things offline, so sorry for throwing yet more options into the ring. Thoughts?
fwiw, Gemini clearly prefers 1 😅
There was a problem hiding this comment.
I gave it now one week of thought. Tbh lifecycle is indeed better. Also because we use lifecycle already in our codebase for such scenarios (e.g. profileLifecycle).
I also thought about naming, I think there is no perfect solution/wording for this one I'm afraid. Let's go for Option 1 of your newest suggestion and see where it leads to.
| await page.locator('#navigate').click(); | ||
| const sessions = (await sessionsPromise).filter(session => session.init); | ||
| expect(sessions.length).toBe(1); |
There was a problem hiding this comment.
l: What I like to do when I test that something is not sent, is to await an event after navigating so that we have some time before ending the tests. I guess in this case, we could wait for an error or a transaction event. There's still an assumption here that the session would have been sent before that event but I think that's reasonable and better than not waiting at all or waiting for a a specific time.
We could even make it more deterministic by:
- going to the page
- awaiting for the init session
- registering the request listener for additional sessions
- navigating
- waiting for the unrelated event
- asserting that no more session envelopes have been sent
There was a problem hiding this comment.
Those are very valid points. I'll try to implement these
| * | ||
| * @default 'navigation' | ||
| */ | ||
| mode?: 'single' | 'navigation'; |
There was a problem hiding this comment.
hmm yeah, "only-pageload" to me also implies something like "we only track sessions for the pageload and stop afterwards".
Let's think about this, also from a perspective of potentially adding a third mode for persisting the id in sessionStorage in the future. So mentally, it should correlate to "short -> medium -> long".
How about:
lifecycle: 'route' | 'page' | 'tab'lifecycle: 'navigation' | 'pageload' | 'tab'
1 has the advantage that it's very descriptive, but confusion could come from "page". I think this is minimal and also kinda works anyway because it's primarily relevant for Single Page applications".
2 is a bit more technical but correlates well with established Sentry terms.
I think with the proper JSDoc (which is already there xD), both would work well. Especially if we pair these with lifecycle since this more directly implies session life time than "mode" IMHO. Fully realizing I said other things offline, so sorry for throwing yet more options into the ring. Thoughts?
fwiw, Gemini clearly prefers 1 😅
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
Uh oh!
There was an error while loading. Please reload this page.
8307b01 to
be3044bComparebe3044b to
2484c0fCompareCodecov Results 📊Generated by Codecov Action |
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
Lms24
left a comment
There was a problem hiding this comment.
Thanks for making the changes, LGTM!
f7824f4 to
ef88277CompareUh oh!
There was an error while loading. Please reload this page.
…ntegration` (#16428) <!-- Use this checklist to make sure your PR is ready for merge. You may delete any sections you don't need. --> ## DESCRIBE YOUR PR Adds docs for getsentry/sentry-javascript#18997. I'd like to merge this before getsentry/sentry-javascript#19341 since it calls out this page in the changelog. ## IS YOUR CHANGE URGENT? Help us prioritize incoming PRs by letting us know when the change needs to go live. - [ ] Urgent deadline (GA date, etc.): <!-- ENTER DATE HERE --> - [ ] Other deadline: <!-- ENTER DATE HERE --> - [ ] None: Not urgent, can wait up to 1 week+ ## SLA - Teamwork makes the dream work, so please add a reviewer to your PRs. - Please give the docs team up to 1 week to review your PR unless you've added an urgent due date to it. Thanks in advance for your help! ## PRE-MERGE CHECKLIST *Make sure you've checked the following before merging your changes:* - [ ] Checked Vercel preview for correctness, including links - [ ] PR was reviewed and approved by any necessary SMEs (subject matter experts) - [ ] PR was reviewed and approved by a member of the [Sentry docs team](https://github.com/orgs/getsentry/teams/docs) ## LEGAL BOILERPLATE <!-- Sentry employees and contractors can delete or ignore this section. --> Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms. ## EXTRA RESOURCES - [Sentry Docs contributor guide](https://docs.sentry.io/contributing/)
closes#18921
closes JS-1526
This adds a new
lifecycleoption to theBrowserSessionIntegration.New explained:
The default is to
routeto not introduce any breaking changeMerge checklist