Re:Robust Client-Side JavaScript (2017)
by jbob2000 on Wednesday June 24, 2020 @02:29PM
(#23631939)
There are many ways the browser can fail. I'm sure their SDK is large because of all the random hacks they need to use to capture everything from every browser. Couple this with the need to create first-class API, which adds some code bloat, and I can see how this ends up at 17K compressed.
[ Parent
| on HN ]
Re:Robust Client-Side JavaScript (2017)
by seanwilson on Wednesday June 24, 2020 @02:37PM
(#23632047)
Why can't they do the shim approach while the library loads though?
Google Analytics for example lets you push everything you want to record into a plain global array called "ga", and when the library loads, everything in the array in processed by the library. This lets you start capturing events without waiting for the library to load.
Re:Robust Client-Side JavaScript (2017)
by the_gipsy on Wednesday June 24, 2020 @06:15PM
(#23634477)
it's a bit different though, you can't "push" errors somewhere, I guess so many error handlers and interceptors are set that it's not worth to split.
Re:Robust Client-Side JavaScript (2017)
by seanwilson on Wednesday June 24, 2020 @10:56PM
(#23636414)
> you can't "push" errors somewhere
Why? Can't you push the Error object or stack trace into an array to await processing?
What if the thing that is pushing the error object has an error?
I think it's more to get as much context as possible. One of our older products just sets window.onerror [0] to a small function that sends the information back to the server, which then forwards it to Sentry. The information in Sentry is nowhere near as detailed as if it came from Sentry's library, but it's been enough for us and doesn't seem to miss anything.
[0] https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...