Skip to content
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

[UI/UX] Error boundaries #3231

Open
ashwin-pc opened this issue Jan 9, 2023 · 2 comments
Open

[UI/UX] Error boundaries #3231

ashwin-pc opened this issue Jan 9, 2023 · 2 comments
Labels
ux / ui Improvements or additions to user experience, flows, components, UI elements

Comments

@ashwin-pc
Copy link
Member

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.

  1. EuiErrorBoundary (Visualize app)
  2. MountPointPortalErrorBoundary (React utils Lib)
  3. As a part of a component (DocViewerTab)
  4. 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.
@ashwin-pc ashwin-pc added the ux / ui Improvements or additions to user experience, flows, components, UI elements label Jan 9, 2023
@ashwin-pc
Copy link
Member Author

cc: @KrooshalUX

@KrooshalUX
Copy link

KrooshalUX commented Jan 18, 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ux / ui Improvements or additions to user experience, flows, components, UI elements
Projects
None yet
Development

No branches or pull requests

2 participants