-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
We want to re-vist our loader (which only works for errors), and deliver a similar experience for performance and replays.
To make this work we first need to gather stats about loader usage and clean up the existing loader code:
### Info Gathering
- [x] https://github.com/getsentry/sentry-javascript/issues/6990
- [x] https://github.com/getsentry/sentry-javascript/issues/6991
We then need to build out infra to generate new bundles that can be served through a loader mechanism. Think of this as a CDN replacement:
### V0
- [ ] https://github.com/getsentry/sentry-javascript/issues/7066
- [x] Document errors + replay CDN bundle
- [ ] https://github.com/getsentry/sentry/issues/44225
- [ ] https://github.com/getsentry/sentry-javascript/issues/7367
- [ ] Add checkbox loader UI to docs
- [ ] https://github.com/getsentry/sentry/issues/46368
- [ ] https://github.com/getsentry/sentry/pull/46926
- [x] <script/> Tag around Loader snippets
- [x] Docs changes
- [ ] https://github.com/getsentry/sentry-docs/pull/6601
- [ ] Measure how many click back to NPM / Yarn Package installation
V1
(follow-up project)
The goal of the loader is to ship the JS to the user to provide the most value. Think of it like this, people just paste the script into their website and we always make sure we have enough data for every error & transaction to provide the most insight. So let's think of this scenario: An error is happening at the user's detail page `GET /users/:id` The loader should capture enough transactions on this URL to understand which requests are happening and also what might be slow. In addition, we want to make sure there is at least also always one Replay available to capture what's actually going on.Therefore when an end user hits the loader - we need to determine on the fly what feature set we ship.
Just errors / errors+performance / or errors+performance+replays.
This should align with how we make decisions currently with Dynamic Sampling.
Again, the end goal of the loader is that we give our users the most insight for an affordable price with zero configuration needed on their end.
Q&A
What specific SDK's are we targeting for the initial roll out?
The first version focuses on the plain Browser SDK since we expect the majority of our users that use a framework like React/Angular have a bundler running and prefer our npm package.