629708beda
Summary: <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot. But native crashes were (and still are) much harder to diagnose. ..Until now :D I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help. The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr). I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly. I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling. After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it. In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`. The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym. I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code. Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost! Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice. I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above. [iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them. [General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode. Pull Request resolved: https://github.com/facebook/react-native/pull/23691 Reviewed By: fkgozali Differential Revision: D14276366 Pulled By: cpojer fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
RNTester
The RNTester showcases React Native views and modules.
Running this app
Before running the app, make sure you ran:
git clone https://github.com/facebook/react-native.git
cd react-native
npm install
Running on iOS
Both macOS and Xcode are required.
- Open
RNTester/RNTester.xcodeprojin Xcode - Hit the Run button
See Running on device if you want to use a physical device.
Running on iOS with CocoaPods
Similar to above, you can build the app via Xcode with help of CocoaPods.
- Install CocoaPods
- Run
cd RNTester; pod install - Open the generated
RNTesterPods.xcworkspace(this is not checked in). Do not openRNTesterPods.xcodeprojdirectly.
Running on Android
You'll need to have all the prerequisites (SDK, NDK) for Building React Native installed.
Start an Android emulator (Genymotion is recommended).
cd react-native
./gradlew :RNTester:android:app:installDebug
./scripts/packager.sh
Note: Building for the first time can take a while.
Open the RNTester app in your emulator.
See Running on Device in case you want to use a physical device.
Running with Buck
Follow the same setup as running with gradle.
Install Buck from here.
Run the following commands from the react-native folder:
./gradlew :ReactAndroid:packageReactNdkLibsForBuck
buck fetch rntester
buck install -r rntester
./scripts/packager.sh
Note: The native libs are still built using gradle. Full build with buck is coming soon(tm).
Running Detox Tests on iOS
Install Detox from here.
To run the e2e tests locally, run the following commands from the react-native folder:
yarn build-ios-e2e
yarn test-ios-e2e
These are the equivalent of running:
detox build -c ios.sim.release
detox test -c ios.sim.release --cleanup
These build the app in Release mode, so the production code is bundled and included in the built app.
When developing E2E tests, you may want to run in development mode, so that changes to the production code show up immediately. To do this, run:
detox build -c ios.sim.debug
detox test -c ios.sim.debug
You will also need to have Metro Bundler running in another terminal. Note that if you've previously run the E2E tests in release mode, you may need to delete the RNTester/build folder before rerunning detox build.
Built from source
Building the app on both iOS and Android means building the React Native framework from source. This way you're running the latest native and JS code the way you see it in your clone of the github repo.
This is different from apps created using react-native init which have a dependency on a specific version of React Native JS and native code, declared in a package.json file (and build.gradle for Android apps).