-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(feedback): use custom prepare/send, re-use createEventEnvelope from core #9432
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
e274114
to
7543baf
Compare
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.
If you're reviewing, I'd suggesting viewing the diff between the last 2 diffs as they are 2 diff implementations: client.captureEvent vs a custom capture.
return client.captureEvent( | ||
baseEvent, | ||
{ | ||
event_id: uuid4(), | ||
}, |
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.
What are the trade offs for using captureEvent
@mydea? We haven't really talked about any hooks that would be needed, but could be a possibility down the road. This would save us from having a lot of custom code, but I don't know how to find out if captureEvent
fails so that we can show the user an error.
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.
I think the core thing is for it to go through event processors etc. Which we have to think about if we want this even 🤔
size-limit report 📦
|
9c4c7cc
to
cc43a04
Compare
7543baf
to
1a49823
Compare
f88ddde
to
380d8fe
Compare
@@ -4,6 +4,7 @@ export type { OfflineStore, OfflineTransportOptions } from './transports/offline | |||
export type { ServerRuntimeClientOptions } from './server-runtime-client'; | |||
|
|||
export * from './tracing'; | |||
export { createEventEnvelope } from './envelope'; |
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.
Are we good to export this @mydea?
This also means we'll have to wait for an SDK release before we can release a new version of the SDK
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.
fine by me! 👍
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.
schema etc. looks good to me. only other thought is i'm wondering if the feedback context should set some kind of signifier that it's the "widget". maybe referrer:widget
or feedback_source:widget
?
thinking we can do the same for crash report, e.g. feedback_source:crash_report
Remove the use of our temporary ingest endpoint, and use our normal ingestion instead.