This warning is at the top of the documentation for the react-native support:
"The React Native plugin is experimental, and not ready for production use."
https://docs.getsentry.com/hosted/clients/javascript/integrations/react-native/
I didn't see an issue for tracking when this will be ready for production so I'm creating this here.
"Not ready for production use" is a little extreme. I'll probably remove that.
What we meant is 鈥撀爓e don't have a good history of people running this on production apps, and we've found React Native to have middling support for source maps (they've added it, killed it, and re-added it between minor revs), so we can't give it a full, ringing endorsement. But we have run it ourselves with some success (for demo/example purposes), and we'll be glad to work with you to make sure that it is successful.
@benvinegar Could you give some pointers for "demo/example" you mentioned if possible? I am still struggling to get everything up and running and with sourceMap working properly. Would really appreciate it.
I'm trying to ensure that my React Native app works right in situations with spotty data coverage. Unfortunately it looks like the Raven transport with React Native doesn't try to persist exceptions to disk when there isn't a network connection. Would you consider buffering exception reports in AsyncStorage
until a connection is available to upload them?
I am experiencing that error as well - js code on iOS does not send anything because crash is just too fast for it to talk to Sentry (my guess).
Going to create a 3rd party module for that since I need a working solution today and if that's somehow aligned with getsentry guys vision, I'd be more than happy to work on merging that :)
Functionality-wise it will act just like raven-objc uncaught exception handler.
@grabbou cool, when you have that ready please let me know!
Here's the gist https://gist.github.com/grabbou/742e08f633557edf7358
You will have to download errio
module from npm (so far seems to be the easiest way to serialize entire error with its stack) but we could potentially use some react-native internals for parsing errors to string back and forth.
Then, simply do:
import {AppRegistry} from 'react-native';
import errorReporter from './errorReporter';
class App extends React.Component {
componentWillMount() {
errorReporter();
}
render() {
return (...);
};
}
AppRegistry.registerComponent('App', () => App);
Works well so far (at least it solved the iOS issue mentioned earlier). Happy to submit a PR with refined code once anyone from @getsentry/raven-js checks if it's worth contributing.
If you'd like to give it a go and add Raven errors handling (when it fails, do not clearException
) as well as change AsyncStorage from being a single item to being an array so we can store multiple exceptions (e.g. 5 crashes w/o internet), that'd be cool. We might look into that later, but so far it's good enough for our use-case.
FYI we're absolutely interested in proper offline support for react-native. Internally we've been talking about the fact that it'd probably be best if we simply made a react-native SDK (which would use raven.js under the hood). e.g. 'sentry-react-native' would become the package, rather than the awkward plugin scenario we have today.
@dcramer that sounds great. Robust offline support is important. The highest priority for me personally is confidence that I'm actually getting reports from the errors my users are experiencing so I can react to them.
Other nice-to-haves would be 1) some way to better automate the source map generation/upload and 2) automatic capture iOS and Android native errors as well as the Javascript ones.
FYI you can fetch source maps in development just like React Native.
I would expect potential sentry React Native client to also support native uncaught exceptions via the raven-objc as in some cases, we also write Objective-C. That should be easily configureable.
We could use rnpm plugin for uploading source maps to sentry automatically (our rnpm is getting merged into rn core soon, so that seems like a good alternative)
@dcramer you may want to consider a React Native variant of the ObjC & Java libs for better RN support, as well (see #533 for a rationale)
Related issue raised in React Native repo.
Removed in #703
Most helpful comment
FYI we're absolutely interested in proper offline support for react-native. Internally we've been talking about the fact that it'd probably be best if we simply made a react-native SDK (which would use raven.js under the hood). e.g. 'sentry-react-native' would become the package, rather than the awkward plugin scenario we have today.