Summary:
This diff check if warnings are ignored before calling through to the wrapped console.warn implementation below, thus preventing ignored logs from being sent to adb/metro/flipper and cleaning them up a bit.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18239936
fbshipit-source-id: 533beced3e66ad1a4d0810933862c63a0b88628c
Summary:
This diff adds support for thrown exceptions to redboxes, and hides the native redbox when we show an error in LogBox.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18212064
fbshipit-source-id: 92031d554968bcb079f81568673ae85697c8f5ad
Summary:
Currently if you land of a surface with a lot of logs, we're basically blocked until they stop. This diff schedules the log parsing in LogBox to free up the app to do other things.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18203391
fbshipit-source-id: 35c5f03316a1106a3a48e7770d5bb59c62a3694f
Summary:
This diff adds a level to LogBox logs so that we can store and display errors in later diffs
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18091101
fbshipit-source-id: 21661d28a7945bdcb56702e2a03ab3612c11fe35
Summary:
This diff improves LogBox performance by not storing and updating logs that are ignored.
Previous we stored all logs, including ignored, as a set. This was so that later, when we show a list of all logs, we would be able to show the ignored logs as well if toggled on. We stored the logs as:
```
const logs = new Set([
{
message: "Not ignored",
ignored: false,
},
{
message: "Ignored",
ignored: true,
},
// 100s more ignored logs
]);
```
But it turns out, we can have hundreds of ignored logs within seconds in some parts of the app. This means we we're re-rendering the LogBoxContainer hundreds of times with a filter on this set to filter out the ignored logs, just to change none of the content.
Now we store as:
```
const logs = new Set([
{
message: "Not ignored",
},
]);
```
Later, when we want to show ignored logs, we'll store these separately.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18055799
fbshipit-source-id: f5e21f66bb4ab6137d5d3908e8c03e119e3805d5
Summary:
In YellowBox we were parsing the component stack trace in a narrow set of use cases, which are commonly missed (I see this working ~50% of the time). That seems to be overly cautious. In LogBox, since there's a nice UI for component stack traces, let's be more aggressive about finding the component stack and we can address it with feedback if we find that there are real issues with this strategy in practice
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D18053389
fbshipit-source-id: 48f116e2bd3f8cc43d53d3668fd6d5b8d7cba2a4
Rick Hanlon