-
Notifications
You must be signed in to change notification settings - Fork 45.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make hard JS indexof not found error more developer-friendly #24744
base: main
Are you sure you want to change the base?
Conversation
…dexOf'. Throw a more specific error with a clue about what parentInstance.child actually was when it was called incorrectly. Add the check to removeChild, since that gets called with the same invalid parentInstance even though addChild threw and never completed.
Comparing: 56389e8...7ba1e65 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated. |
bump |
Summary
While debugging some new console output in the debugger complaining about a call attempt on a non-function, I found this test's
toThrow()
was meant to capture the hard JS error, but wasn't specific. To make the toThrow() more specific, and provide more helpful information in the error, I crafted a more developer-friendly message to include in the thrown Error that should save a debugging cycle for the next people that run into it. I noticed that I had to add the check in removeChild as well, which attempted to callindexOf
on the same invalidparentInstance.children
without checking the type.How did you test this change?
I augmented the existing test to verify the specific user-friendly thrown error, and added a second test case that captures the original abuse case whose debugging led me to discover this issue.
yarn test
andyarn test --prod
both pass on my x64 MacBook Pro running MacOS 12.4 and the node version specified in the repo's .nvmrc file.