Summary: `parseErrorStack` (which uses the `stacktrace-parser` package) can return null file names, line numbers and column numbers. This diff updates the associated types and adds explicit null checks in some call sites.
Reviewed By: rickhanlonii
Differential Revision: D16542176
fbshipit-source-id: b72c73c05b95df0bbcb5b5baa7bc2d42cff1e074
Summary:
# Context
In https://github.com/facebook/react/pull/16141 we imported `ReactFiberErrorDialog` unchanged from React. That implementation was not idempotent: if passed the same error instance multiple times, it would amend its `message` property every time, eventually leading to bloat and low-signal logs.
The message bloat problem is most evident when rendering multiple `lazy()` components that expose the same Error reference to React (e.g. due to some cache that vends the same rejected Promise multiple times).
More broadly, there's a need for structured, machine-readable logging to replace stringly-typed interfaces in both the production and development use cases.
# This diff
* We leave the user-supplied `message` field intact and instead do all the formatting inside `ExceptionsManager`. To avoid needless complexity, this **doesn't** always have the exact same output as the old code (but it does come close). See tests for the specifics.
* The only mutation we do on React-captured error instances is setting the `componentStack` expando property. This replaces any previously-captured component stack rather than adding to it, and so doesn't create bloat.
* We also report the exception fields `componentStack`, unformatted `message` (as `originalMessage`) and `name` directly to `NativeExceptionsManager` for future use.
Reviewed By: cpojer
Differential Revision: D16331228
fbshipit-source-id: 7b0539c2c83c7dd4e56db8508afcf367931ac71d
Summary:
@public
`reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated.
In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`).
This change is backwards compatible in two senses:
1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable.
2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`.
Naturally, both fallbacks mentioned above discard `extraData`.
NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback.
While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes.
Reviewed By: mmmulani
Differential Revision: D16133080
fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
Summary:
This is another step in moving RN towards standard path-based requires, updating more code to use path-based requires. See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
## Changelog
[General] [Changed] - Replace more Haste imports with path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25001
Differential Revision: D15467829
Pulled By: cpojer
fbshipit-source-id: 58c364bb4c1c757689907d5ed0d0f3fac0e22f3f
Moti Zilberman
James Ide
Michał Pierzchała