You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though we use use Error boundaries throughout the app, there is no consistent way to surface these errors. Opening this issue to discuss the use of error boundaries, how we want to surface these errors and who the intended audience for the error is.
Context
Today in OSD we have as far as i can tell, 4 different ways we show errors using error boundaries.
EuiErrorBoundary (Visualize app)
MountPointPortalErrorBoundary (React utils Lib)
As a part of a component (DocViewerTab)
EditorErrorBoundary (Visbuilder)
Although it would seem that the EuiErrorBoundray should be used in all cases, thats is not ideal because the default boundary spits out a stack trace that is not useful to the user with useful information about how to the actual error. This is probably why there is only a single instance of EuiErrorBoundary being used in the app.
Proposed solution:
Update errors to have an error code and a user facing message associated with them that can be cataloged and is searchable by the user.
Update the EuiErrorBoundary component to take in an error message and optional error code that is displayed when an error occurs. The purpose of this message and error code is to serve as a fallback message if the error reaching the boundary does not have an error code.
The new component should display the error stack trace to the browser console instead. (It already does this)
Replace all instances of custom boundaries with standard component.
Alternatives considered:
also surfacing a toast message when an error occurs: I dont think this is a good idea since the boundary is meant to catch unhandled errors, which by definition mean that even after our best efforts to catch errors, something went catastrophically wrong that it reached the boundary. Having a dependency for toasts in this boundary will defeat the purpose of the boundary.
The text was updated successfully, but these errors were encountered:
ashwin-pc
added
the
ux / ui
Improvements or additions to user experience, flows, components, UI elements
label
Jan 9, 2023
@ashwin-pc I am onboard with updating OuiErrorBoundary as a way to achieve visual & implementation alignment across the project. Primarily interested in knowing if you see these updates having any impact on the visual aspect of the component , or simply the implementation.
Can you elaborate on your first point within proposed solution - especially around what it might take within OSD and plug-ins to create this mapping of error codes & messages (outside of providing the error messages themselves). Do you see any potential blockers?
Even though we use use Error boundaries throughout the app, there is no consistent way to surface these errors. Opening this issue to discuss the use of error boundaries, how we want to surface these errors and who the intended audience for the error is.
Context
Today in OSD we have as far as i can tell, 4 different ways we show errors using error boundaries.
EuiErrorBoundary
(Visualize app)MountPointPortalErrorBoundary
(React utils Lib)EditorErrorBoundary
(Visbuilder)Although it would seem that the
EuiErrorBoundray
should be used in all cases, thats is not ideal because the default boundary spits out a stack trace that is not useful to the user with useful information about how to the actual error. This is probably why there is only a single instance ofEuiErrorBoundary
being used in the app.Proposed solution:
EuiErrorBoundary
component to take in an error message and optional error code that is displayed when an error occurs. The purpose of this message and error code is to serve as a fallback message if the error reaching the boundary does not have an error code.Alternatives considered:
The text was updated successfully, but these errors were encountered: