feat: Add no-sidecar Sentry SDK integration for overlay

[BYK]

Ref #133.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
spotlightjs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 28, 2024 2:36pm

[BYK]

Okay this works but we need some persistent storage as the events don't survive across page loads or even a simple reload.

[BYK]

@Lms24 any thoughts here? This is to close #133

[BYK]

Seemingly best way forward:

• Use IndexedDB with expiry as shown in https://stackoverflow.com/a/35518068/90297
• On initialization (afterAllSetup), expire all stored and expired events, send rest to Spotlight
• Store each envelope in beforeSend hook before forwarding to Spotlight

[Lms24]

Why do we need to care about previously expired events? I'm not yet sure I understand why we'd need to store anything in IndexdDB. Here's what I'm currently thinking:

1. Spotlight Overlay and Sentry SDK (with spotlight integration) intialize on page load
2. Sentry SDK sends event
3. Spotlight Sentry integration's beforeEnvelope listener is invoked and forwards the event via trigger('event',...)
4. Event appears in spotlight
5. When page is reloaded/hard navigation to next step -> back to step 1

I guess the only advantage we'd get with storing events is that we can show events from past page loads. Which is probably not always what we/users want but I can see it being helpful. If that's the goal then let's do it but IMO, this is something we should handle within spotlight and independent of if the event came in from the sidecar or from the event target.

[Lms24]

whoops, sorry for the accidental close!

[BYK]

I guess the only advantage we'd get with storing events is that we can show events from past page loads. Which is probably not always what we/users want but I can see it being helpful. If that's the goal then let's do it but IMO, this is something we should handle within spotlight and independent of if the event came in from the sidecar or from the event target.

This is the current state anyway. Sidecar stores all past events (and without expiry which we may wanna address in the future due to memory concerns), and replays them as the first thing when a connection is made. When a user goes through pages or reloads, the events persist. In my own testing, I was also surprised when they were missing.

Regarding at which level this should be done, I agree it makes sense to move it to Spotlight core so I'll tie this in to the new manual event trigger system.

[Lms24]

Sounds good to me! Though I'm a bit concerned with the TS bump (see comments). Given 5.4 isn't that old yet, I suggest we think twice if we need to bump it. I think in this case, rewriting Promise.withResolvers should be doable. If you still want to bump, we can of course also cut a major.

[Lms24]

LGTM! Thanks for making the changes!