feat(react): Add a handled prop to ErrorBoundary

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.

[HHK1]

The previous behaviour was to rely on the presence of the fallback prop to decide if the error was considered handled or not. The new property lets the consumer explicitely choose what should the handled status be.
If omitted, the old behaviour is still applied.

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

-> I'm having some failures locally that seem unrelated to my changes. Waiting for a CI check to confirm

[HHK1]

@Lms24 not sure what to do regarding the CI.

build works fine locally, but I'm having errors when running lint and test. It seems very much unrelated to the changes here.
Any advices on making the local setup work?

[Lms24]

Hey @HHK1 thanks for opening this PR! The proposed changes look good to me! I had some suggestions to streamline the implementation but looks fine! I'll start CI to check for the linting stuff but it most definitely will fail because there's still an .only filter in the tests (we have a lint rule against accidentally merging this in).

I'd generally recommend to run yarn fix:biome in the root directory of the repo to fix any formatting and biome lint issues.

I can take another look about remaining CI fails if things still fail after the changes.

[Lms24]

a suggestion to make this a bit more concise and save some bytes of bundle size. I turned around the condition to reflect that the fallback is actually our fallback way of determining handled:

Suggested change

	constisHandled=this.props.handled===undefined ? !!this.props.fallback : this.props.handled;
	consteventId=captureReactException(error,errorInfo,{mechanism: {handled: isHandled}});
	consthandled=this.props.handled!=null ? this.props.handled : !!this.props.fallback;
	consteventId=captureReactException(error,errorInfo,{mechanism: { handled }});

(!= null can be used as a shorthand for !== undefined && !== null)

[HHK1]

Fixed in 11c408d

[Lms24]

This we should most definitely remove :)

Suggested change

	it.only.each`
	it.each`

[HHK1]

fixed in 9c1cf83

[HHK1]

@Lms24 thanks for the review!

I've pushed a couple fixups, once the conversations are resolved I'll squash them to have a single commit.

I ran the formatting through the VSCode extension on the files I've touched, but I got the following kind of issues when running yarn run lint locally at the root of the repo:

Formatter would have printed the following content:
3 3 │ import type { RouterType } from './server/solidrouter';
4 4 │ export declare function withSentryRouterRouting(Router: RouterType): RouterType;
5 │ - //#·sourceMappingURL=solidrouter.d.ts.map
5 │ + //#·sourceMappingURL=solidrouter.d.ts.map
6 │

The yarn test command is also failing:

 FAIL test/reactrouterv3.test.tsx
● Test suite failed to run
test/reactrouterv3.test.tsx:21:16 - error TS2403: Subsequent variable declarations must have the same type. Variable 'Router' must be of type 'typeof import("/Users/henryhuck/Documents/oss/sentry-javascript/node_modules/react-router/lib/Router")', but here has type 'ComponentType<{ history: History; }>'.
21 export const Router: React.ComponentType<{ history: History }>;

It does seem like a local setup error. Rings any bell? Not a big deal but I was just curious as why it could fail.

[HHK1]

@Lms24 just a soft ping if you could have a look 😇🙏
I think everything is good now, let me know if you want me to squash the fixups before re-running the CI (I use them to make the changes clearer to re-review).

[HHK1]

@Lms24 👋 would it be possible to have a review on this please?

[Lms24]

Apologies for the late review! This looks good to me now, thanks for contributing and for making the requested changes :)

Heads-up: I'll cherry pick this commit once it's merged onto our v8 branch to ensure we can include this in the next v8 release, probably sometime next week.