2019-10-22 07:05:47 +03:00
|
|
|
/**
|
|
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
|
|
|
*
|
|
|
|
* @flow
|
|
|
|
* @format
|
|
|
|
*/
|
|
|
|
|
|
|
|
'use strict';
|
|
|
|
|
|
|
|
import UTFSequence from '../../UTFSequence';
|
|
|
|
import stringifySafe from '../../Utilities/stringifySafe';
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
import type {ExceptionData} from '../../Core/NativeExceptionsManager';
|
2019-11-13 22:30:43 +03:00
|
|
|
import type {LogBoxLogData} from './LogBoxLog';
|
2019-10-22 07:05:47 +03:00
|
|
|
|
2019-11-13 22:30:43 +03:00
|
|
|
export type ExtendedExceptionData = ExceptionData & {isComponentError: boolean};
|
2019-10-22 07:05:47 +03:00
|
|
|
export type Category = string;
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
export type CodeFrame = $ReadOnly<{|
|
|
|
|
content: string,
|
2019-11-07 20:10:13 +03:00
|
|
|
location: {
|
|
|
|
row: number,
|
|
|
|
column: number,
|
|
|
|
},
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
fileName: string,
|
|
|
|
|}>;
|
2019-10-22 07:05:47 +03:00
|
|
|
export type Message = $ReadOnly<{|
|
|
|
|
content: string,
|
|
|
|
substitutions: $ReadOnlyArray<
|
|
|
|
$ReadOnly<{|
|
|
|
|
length: number,
|
|
|
|
offset: number,
|
|
|
|
|}>,
|
|
|
|
>,
|
|
|
|
|}>;
|
|
|
|
|
|
|
|
export type ComponentStack = $ReadOnlyArray<
|
|
|
|
$ReadOnly<{|
|
|
|
|
component: string,
|
|
|
|
location: string,
|
|
|
|
|}>,
|
|
|
|
>;
|
|
|
|
|
|
|
|
const SUBSTITUTION = UTFSequence.BOM + '%s';
|
|
|
|
|
2019-11-01 02:22:38 +03:00
|
|
|
export function parseCategory(
|
2019-10-22 07:05:47 +03:00
|
|
|
args: $ReadOnlyArray<mixed>,
|
|
|
|
): $ReadOnly<{|
|
|
|
|
category: Category,
|
|
|
|
message: Message,
|
|
|
|
|}> {
|
|
|
|
const categoryParts = [];
|
|
|
|
const contentParts = [];
|
|
|
|
const substitutionOffsets = [];
|
|
|
|
|
|
|
|
const remaining = [...args];
|
|
|
|
if (typeof remaining[0] === 'string') {
|
|
|
|
const formatString = String(remaining.shift());
|
|
|
|
const formatStringParts = formatString.split('%s');
|
|
|
|
const substitutionCount = formatStringParts.length - 1;
|
|
|
|
const substitutions = remaining.splice(0, substitutionCount);
|
|
|
|
|
|
|
|
let categoryString = '';
|
|
|
|
let contentString = '';
|
|
|
|
|
|
|
|
let substitutionIndex = 0;
|
|
|
|
for (const formatStringPart of formatStringParts) {
|
|
|
|
categoryString += formatStringPart;
|
|
|
|
contentString += formatStringPart;
|
|
|
|
|
|
|
|
if (substitutionIndex < substitutionCount) {
|
|
|
|
if (substitutionIndex < substitutions.length) {
|
|
|
|
// Don't stringify a string type.
|
|
|
|
// It adds quotation mark wrappers around the string,
|
|
|
|
// which causes the LogBox to look odd.
|
|
|
|
const substitution =
|
|
|
|
typeof substitutions[substitutionIndex] === 'string'
|
|
|
|
? substitutions[substitutionIndex]
|
|
|
|
: stringifySafe(substitutions[substitutionIndex]);
|
|
|
|
substitutionOffsets.push({
|
|
|
|
length: substitution.length,
|
|
|
|
offset: contentString.length,
|
|
|
|
});
|
|
|
|
|
|
|
|
categoryString += SUBSTITUTION;
|
|
|
|
contentString += substitution;
|
|
|
|
} else {
|
|
|
|
substitutionOffsets.push({
|
|
|
|
length: 2,
|
|
|
|
offset: contentString.length,
|
|
|
|
});
|
|
|
|
|
|
|
|
categoryString += '%s';
|
|
|
|
contentString += '%s';
|
|
|
|
}
|
|
|
|
|
|
|
|
substitutionIndex++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
categoryParts.push(categoryString);
|
|
|
|
contentParts.push(contentString);
|
|
|
|
}
|
|
|
|
|
|
|
|
const remainingArgs = remaining.map(arg => {
|
|
|
|
// Don't stringify a string type.
|
|
|
|
// It adds quotation mark wrappers around the string,
|
|
|
|
// which causes the LogBox to look odd.
|
|
|
|
return typeof arg === 'string' ? arg : stringifySafe(arg);
|
|
|
|
});
|
|
|
|
categoryParts.push(...remainingArgs);
|
|
|
|
contentParts.push(...remainingArgs);
|
|
|
|
|
|
|
|
return {
|
|
|
|
category: categoryParts.join(' '),
|
|
|
|
message: {
|
|
|
|
content: contentParts.join(' '),
|
|
|
|
substitutions: substitutionOffsets,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
}
|
2019-11-01 02:22:38 +03:00
|
|
|
export function parseComponentStack(message: string): ComponentStack {
|
|
|
|
return message
|
|
|
|
.split(/\n {4}in /g)
|
|
|
|
.map(s => {
|
|
|
|
if (!s) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
let [component, location] = s.split(/ \(at /);
|
|
|
|
if (!location) {
|
|
|
|
[component, location] = s.split(/ \(/);
|
|
|
|
}
|
|
|
|
return {component, location: location && location.replace(')', '')};
|
|
|
|
})
|
|
|
|
.filter(Boolean);
|
|
|
|
}
|
2019-10-22 07:05:47 +03:00
|
|
|
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
export function parseLogBoxException(
|
2019-11-13 22:30:43 +03:00
|
|
|
error: ExtendedExceptionData,
|
2019-11-13 22:30:43 +03:00
|
|
|
): LogBoxLogData {
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
const message =
|
|
|
|
error.originalMessage != null ? error.originalMessage : 'Unknown';
|
|
|
|
const match = message.match(
|
2019-11-07 20:10:13 +03:00
|
|
|
/(?:TransformError )?(?:SyntaxError: )(.*): (.*) \((\d+):(\d+)\)\n\n([\s\S]+)/,
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
);
|
|
|
|
|
|
|
|
if (!match) {
|
|
|
|
return {
|
2019-11-13 22:30:43 +03:00
|
|
|
level: error.isFatal || error.isComponentError ? 'fatal' : 'error',
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
stack: error.stack,
|
2019-11-13 22:30:43 +03:00
|
|
|
isComponentError: error.isComponentError,
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
componentStack:
|
|
|
|
error.componentStack != null
|
|
|
|
? parseComponentStack(error.componentStack)
|
|
|
|
: [],
|
|
|
|
...parseCategory([message]),
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-11-07 20:10:13 +03:00
|
|
|
const [fileName, content, row, column, codeFrame] = match.slice(1);
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
return {
|
|
|
|
level: 'syntax',
|
|
|
|
stack: [],
|
2019-11-13 22:30:43 +03:00
|
|
|
isComponentError: false,
|
|
|
|
componentStack: [],
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
codeFrame: {
|
|
|
|
fileName,
|
2019-11-07 20:10:13 +03:00
|
|
|
location: {
|
|
|
|
row: parseInt(row, 10),
|
|
|
|
column: parseInt(column, 10),
|
|
|
|
},
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
content: codeFrame,
|
|
|
|
},
|
|
|
|
message: {
|
|
|
|
content,
|
|
|
|
substitutions: [],
|
|
|
|
},
|
2019-11-07 20:10:13 +03:00
|
|
|
category: `${fileName}-${row}-${column}`,
|
LogBox - Add syntax error handling
Summary:
This diff adds handling for syntax errors.
## Strategy
To do this we introduce a new log level type syntax, giving us these levels with semantics:
- `warn` - console warns, show collapsed, dismissible
- `error` - console errors, show collapsed, dismissible
- `fatal` - thrown exceptions, show expanded, not dismissible
- `syntax` - thrown exceptions for invalid syntax, show expanded, not dismissible
Syntax errors shows expanded, covers all other errors, and are only dismissible when the syntax error is fixed and updated with Fast Refresh. Once the syntax error is fixed, it reveals any previously covered fatals, errors, or warnings behind it
In many ways, this makes syntax errors the highest level error.
## Visuals
Syntax errors also have their own display formatting. Stack traces for syntax errors don't make sense, so we don't show them. Instead, we show the syntax error message and a code frame for the error.
The code frame is also updated so that is doesn't wrap and is horizontally scrollable, making it easier to read.
## Detecting syntax errors
To detect syntax errors we've updated `LogBoxData.addException` to call the parse function `parseLogBoxException`. This method will perform a regex on the error message to detect:
- file name
- location
- error message
- codeframe
If this regex fails for any reason to find all four parts, we'll fall back to a fatal. Over time we'll update this regex to be more robust and handle more cases we've missed.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18278862
fbshipit-source-id: 59069aba38a27c44787e5248b2973c3a345c4a0a
2019-11-02 02:05:02 +03:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-11-01 02:22:38 +03:00
|
|
|
export function parseLogBoxLog(
|
2019-10-22 07:05:47 +03:00
|
|
|
args: $ReadOnlyArray<mixed>,
|
2019-10-22 23:59:44 +03:00
|
|
|
): {|
|
2019-10-22 07:05:47 +03:00
|
|
|
componentStack: ComponentStack,
|
|
|
|
category: Category,
|
|
|
|
message: Message,
|
|
|
|
|} {
|
|
|
|
// This detects a very narrow case of a simple log string,
|
|
|
|
// with a component stack appended by React DevTools.
|
|
|
|
// In this case, we extract the component stack,
|
|
|
|
// because LogBox formats those pleasantly.
|
|
|
|
// If there are other substitutions or formatting,
|
2019-10-22 23:59:44 +03:00
|
|
|
// this could potentially corrupt the data, but there
|
|
|
|
// are currently no known cases of that happening.
|
2019-10-22 07:05:47 +03:00
|
|
|
let componentStack = [];
|
2019-10-22 23:59:44 +03:00
|
|
|
let argsWithoutComponentStack = [];
|
|
|
|
for (const arg of args) {
|
|
|
|
if (typeof arg === 'string' && /^\n {4}in/.exec(arg)) {
|
2019-11-01 02:22:38 +03:00
|
|
|
componentStack = parseComponentStack(arg);
|
2019-10-22 23:59:44 +03:00
|
|
|
} else {
|
|
|
|
argsWithoutComponentStack.push(arg);
|
2019-10-22 07:05:47 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
2019-10-22 23:59:44 +03:00
|
|
|
...parseCategory(argsWithoutComponentStack),
|
2019-10-22 07:05:47 +03:00
|
|
|
componentStack,
|
|
|
|
};
|
|
|
|
}
|