Sentry-javascript: React-Native End-to-End Example

Created on 18 Oct 2016  路  9Comments  路  Source: getsentry/sentry-javascript

I've read the docs, but they gloss over a few parts on the integrations, so I think it would be really helpful to have a proper React-Native end-to-end example available somewhere.

I've done some github searches trying to find react-native projects that automate the below, to no avail...

In particular:

The react-native doc suggests naming the artifacts specifically. But the sourcemap uploading doc glosses over artifact names, and instead mentions these parameters:

  -F [email protected]
  -F name="http://example.com/app.js.map"

that leave me confused.

In theory, we should be able to extend the existing Android/iOS shell scripts to generate the source-map, create a new release, and upload the files, with the correct names. This would obviate the need for a bunch of documentation and manual plumbing, if this could be made automatic.

Especially if we are using the app-version as the release name in the shell scripts and JS, this shouldn't be too difficult to correlate. This should be fetchable from JS via react-native-device-info.

Most helpful comment

By drop-in usage, I meant react-native-trackjs and react-native-fabric-crashlytics can be used like this and start reporting exceptions:

Sure, same here with our RN plugin. Except if you want source map support (and you should), you have to additionally upload them, which yeah, is extra work unfortunately.

I'll look into adding an end-to-end example.

All 9 comments

I've built RN extensions for uploading JS extensions to trackjs and crashlytics that work, but have heard good things about Sentry's support of sourcemaps, so was interested in exploring it. But given the drop-in nature of what I build for the other two systems, it's hard for me to justify attempting to build a third system given the state of the docs and the amount of trial-and-error and manual work-per-release I'd expect I'd be doing to get it to work. Thus the desire for an end-to-end example (even if it's just a production app I can peek at source for)

I think it would be really helpful to have a proper React-Native end-to-end example available somewhere.

Makes sense. I can put one up on GitHub.

But the sourcemap uploading doc glosses over artifact names, and instead mentions these parameters ...

Artifacts in Sentry are basically just aliases to locations on the web. Sentry originally (and still) fetches sources and source maps from the public web over HTTP, and so artifacts should be viewed from this context.

Have a JavaScript file located at https://example.org/js/app.js? Cool, Sentry will fetch it. But if you don't want it to fetch it, you can upload an artifact literally named https://example.org/js/app.js, and Sentry will look for and use that instead. Same for source maps. That's all artifacts are, and hence why they have seemingly confusing "names" 鈥撀燼rtifacts are almost always "named" as URLs.

But given the drop-in nature of what I build for the other two systems, it's hard for me to justify attempting to build a third system given the state of the docs and the amount of trial-and-error and manual work-per-release I'd expect I'd be doing to get it to work.

I'd love to know what about those processes felt easier. Any feedback would be much appreciated.

Aside: is this really considered drop-in?

Edit: to elaborate, is the source map issue so painful that it was easier to construct this dedicated library (and deal with source maps on another service) instead? If that's true then we are really dropping the ball here 馃槗

Sorry, I should have been clearer. Here's my longer story.

I built trackjs and crashlytics RN wrappers 4-5 months ago in beginning my RN journey, as those were familiar to me pre-RN. I'm not honestly sure why I didn't consider Sentry at the time (unaware of it? pricing concerns? did it lack RN support?)

Neither trackjs nor crashlytics have sourcemap support. And one RN-fabric-crashlytics contributor (who was adding sourcemap support) has mentioned Sentry does a much better job here. So given my personal interest in sourcemaps for my app, I am looking into Sentry.

By drop-in usage, I meant react-native-trackjs and react-native-fabric-crashlytics can be used like this and start reporting exceptions:

import X from 'react-native-X';
X.init(...);

It's not fair to compare them, given that sourcemaps require additional support to upload in Sentry, which neither of those do. But I believe that uploading can be done via the build scripts, and hopefully relatively easily. For example, Crashlytics does it with a run script you add to ios build, and with a gradle plugin that does it on android builds:
https://fabric.io/kits/ios/crashlytics/install
https://fabric.io/kits/android/crashlytics/install

I was hoping to do something similar here (since I do not want to upload sourcemaps manually every time I do a release, as I'm likely to forget them until it's too late). But lacking an end-to-end example, I was anticipating a lot of trial-and-error setup, before I could even get to writing something that automates the process for me. And sourcemaps weren't _that_ critical to me yet, to dive down that rabbit hole... :)

By drop-in usage, I meant react-native-trackjs and react-native-fabric-crashlytics can be used like this and start reporting exceptions:

Sure, same here with our RN plugin. Except if you want source map support (and you should), you have to additionally upload them, which yeah, is extra work unfortunately.

I'll look into adding an end-to-end example.

Thanks for looking into this @benvinegar. I also got stumped by "artifacts" and had to contact support. Please update this issue when the example is ready :)

I could use a solid end-to-end example. I've gotten /main.jsbundle and /main.jsbundle.map in my release artifacts, with the proper sourceMappingURL at the end of the bundle; but I still cannot get the stack traces to work with the source maps.

Sentry now has a first-class React Native client, with mixed JavaScript + iOS frames in stack traces (Android coming soon). It is far better documented, and I'd strongly recommend using it going forward.

(Sorry, I knew this was coming and didn't feel like investing in an example when it'd become moot relatively soon.)

Closing this issue.

Thanks for the update @benvinegar. Using this new project will resolve the minified source issue?

Was this page helpful?
0 / 5 - 0 ratings