ref(browser): Refactor browser integrations to use processEvent#9022
ref(browser): Refactor browser integrations to use processEvent#9022
processEvent#9022Conversation
size-limit report 📦
|
c2d603d to
c354494
Compare
16a892a to
0b42518
Compare
| } | ||
|
|
||
| /** @inheritDoc */ | ||
| public preprocessEvent(event: Event): void { |
There was a problem hiding this comment.
I actually figured this prob. makes sense as preprocess, as we may want to generally run this before all other processing, as the other processings may want to access the request?
Lms24
left a comment
There was a problem hiding this comment.
LGTM (I assume we test most of these integrations anyway in integration tests so we shouldn't need any test adjustments, right?)
Yeah so some tests failed during implementing this (which i fixed by now), so I'd say this should be OK covered! |
|
Tests currently fail because of #9034, fix WIP. |
| }; | ||
| return event; | ||
| }, | ||
| { id: 'Replay' }, |
There was a problem hiding this comment.
this is used to identify which event processor dropped an event (possibly). It's optional, but figured it's good form to add this for all our own event processors!
0ebcde1 to
1a24b5d
Compare
This refactors browser integrations to use the new
processEventhook on the Integrations interface.It also updates Replay to register it's event processor on the client, not globally. This is also needed to ensure the order is somewhat stable, as global processors are run separately from the client ones.