-
Notifications
You must be signed in to change notification settings - Fork 11
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
Ensure errors are caught and resettable #490
Conversation
e4fd27d
to
b6693a0
Compare
We have continued to have some issues with errors that occur during the OSCALLoader (and OSCALLoaderForm) because of the structure of various components and where the errors occur. This implements a quick fix to push the errors down into a child component of OSCALLoader. That component will then throw the error, which can be caught be the ErrorBoundary because it occurs as a child of the ErrorBoundary. This should continue to preserve the form and other UI elements. This has some kinda nasty side effects. The error message in the console will sorta mask the actual location where the error occurred (it will look like it came from the `ErrorThrower`) unless the error itself got logged before that (which seems to usually happen) or unless the error actually occurs somewhere in `{result}` which we've handled pretty correctly for the most part. `ErrorThrower` is deprecated upon creation because wow I really don't want to see this in other places in our code base.
b6693a0
to
4fc469e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works well! Don't see any more problems with this error when testing both the viewer and editor.
I'll admit, I'm not a huge fan of having a deprecated method, but it seems like this is one of the better options for handling the problem right now. I think the issues with state and components interacting with OSCALLoader
have become more and more relevant, and I think it would make sense we try to restructure these in the near future.
This tests changes introduced by EasyDynamics/oscal-react-library#490
This tests changes introduced by EasyDynamics/oscal-react-library#490
We have continued to have some issues with errors that occur during the
OSCALLoader (and OSCALLoaderForm) because of the structure of various
components and where the errors occur. This implements a quick fix to
push the errors down into a child component of OSCALLoader. That
component will then throw the error, which can be caught be the
ErrorBoundary because it occurs as a child of the ErrorBoundary. This
should continue to preserve the form and other UI elements.
This has some kinda nasty side effects. The error message in the console
will sorta mask the actual location where the error occurred (it will
look like it came from the
ErrorThrower
) unless the error itself gotlogged before that (which seems to usually happen) or unless the error
actually occurs somewhere in
{result}
which we've handled prettycorrectly for the most part.
ErrorThrower
is deprecated upon creation because wow I really don'twant to see this in other places in our code base.
Closes #489