-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(replay): Use new prepareEvent util & ensure dropping replays works
#6522
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
Conversation
size-limit report 📦
|
29a7213 to
9521386
Compare
billyvg
left a comment
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.
LGTM
9521386 to
8aaff54
Compare
Lms24
left a comment
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.
Nice work! I'm a little concerned about the bundle size increase though... my guess is that we now bundle prepareEvent into the Replay CDN bundle which causes this increase. I guess we'll just have to take that hit but this def adds to the benefits of a complete bundle (#6573).
| '_support', | ||
| // TODO: Get rid of these once we use the SDK to send replay events | ||
| '_prepareEvent', // replay uses client._prepareEvent | ||
| '_metadata', // replay uses client.getOptions()._metadata |
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.
Side-note: As discussed, I'll take a look if we can get rid of the _metadata entry here
8aaff54 to
7fecdfb
Compare
7fecdfb to
c2ba7be
Compare
NOTE: Depends on #6517
This uses the newly exposed
prepareEventutil from core, and also makes sure that the event processors actually work as expected.General changes:
null(previously, this would error)