Include error stack in <ErrorBoundary>

[rasmuswoelk]

Until now, we have only been rendering the component stack, when the <ErrorBoundary> catches an error.

This update includes the error stack as well which makes it a lot easier to pinpoint where an error occurred at first glance without having to look in the console.

Note

The component stack can be made more precise by wrapping each module in an <ErrorBoundary>.

Before

After

[MikeTaylor]

This is useful, because it adds information. That's always good.

But in fact I'd been under the impression that I was seeing a lower-level stack than the one I wanted, which is at the component level! So you're adding the thing I thought I already had, and I already had (apparently) the thing I thought I wanted!

I gotta go and lie down.

[axelhunn]

Suggested change

	.filter(str => !!str);
	.filter(Boolean);

[zburke]

.filter(Boolean);

Is using the Boolean constructor in this way a common idiom? I mean, I get it, it works, it's a tiny bit shorter. But given .filter() expects to receive a function and Boolean looks nothing like a function, it seems less clear rather than more.

[axelhunn]

I thought it is kinda idiom. Met this many times.
Like https://michaeluloth.com/filter-boolean

[zburke]

Fair. Maybe it's the idiomatic way now, but it wasn't when I learned Javascript back in the 90s 😆 .

[axelhunn]

Who at that time could have known that the language for making falling snowflakes could become the world #1

[zburke]

Hmm, this is different, but unfortunately it's not actually better. I really appreciate the effort though! The error stack is definitely more interesting than the component stack but unless we can show source-mapped line numbers, it still isn't actionable information.

In development mode running yarn local to serve from a workspace, the error stack shows line numbers from the bundle rather than from the original source, which is what we get in the console:

Likewise, in production when serving from a build with sourcemaps enabled, the "Error details" panel appears to still show the component stack. In order for that "Copy" button to copy actionable information, it would need to show the error stack with source-mapped line numbers like the console:

[zburke]

The component stack can be made more precise by wrapping each module in an <ErrorBoundary>.

Aren't they already?

        return modules.app.map((module) => {
          ...
          return (
            ...
                        <RouteErrorBoundary
                          escapeRoute={module.home}
                          moduleName={displayName}
                          stripes={moduleStripes}
                        >
                            ...

[rasmuswoelk]

@zburke You are right – the development error could be a lot more precise. And the production error is basically useless because of the obfuscation.

I found this issue where multiple sugested solutions:
facebook/create-react-app#6667

Here are some of them:

• Use https://github.com/sergei-startsev/babel-plugin-react-displayname-path to improve component stack readability
• Set keep_classnames: true, keep_fnames: /[A-Z].+/, in the webpack terser plugin (not sure if we are using it)
• Use something like https://github.com/stacktracejs/stacktrace.js to get a more readable stack trace when a source map is available

And correct, the modules are wrapped in stripes-core, but I noticed that wrapping the root of the module results in a more precise and relevant component stack (in development at least).

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[rasmuswoelk]

Merging this for now. We can improve on the readability of the stack traces later.