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

feat: Display deephaven.ui widget errors in a panel so user can see them #436

Merged
merged 26 commits into from
May 10, 2024

Conversation

mofojed
Copy link
Member

@mofojed mofojed commented Apr 25, 2024

  • Widget can now emit a documentError on the server to indicate there was an error rendering the document
  • Client listens for documentError and will display the error message in a panel along with a Reload button to reload the widget
  • Updated @deephaven/* packages to 0.76.0, which includes the ErrorView and is also in deephaven-core 0.34.1
  • Fixes Errors not visible when opening deephaven.ui widget from panels menu #437
  • Fixes Render error handling #85
  • Tested with a ui_boom and ui_boom_counter components:
from deephaven import ui

@ui.component
def ui_boom():
    raise Exception("BOOM!")

@ui.component
def ui_boom_counter():
    value, set_value = ui.use_state(0)

    if value > 5:
        raise ValueError("BOOM! Value is bigger than 5.")
    
    return ui.button(f"Count is {value}", on_press=lambda: set_value(value + 1))

boom = ui_boom()
boom_counter = ui_boom_counter()

- Add an error listener to a command
- WIP, does not actually display the error yet but is wired up to listen to it.
  - Need to pass the error down to `DocumentHandler`? Or have a separate `DocumentErrorHandler` widget?
- Errors now display in a panel
- Still need to clean up the look of it, add a Reload button
- TODO: Fix the Reload button. Doesn't quite seem to be working.
- We just send a state reset to the object on the server
- If we're currently re-rendering we shouldn't emit the close
- If a callback throws, display a document error
- It could be possible for a component to expect an error to be thrown and it could handle that exception... I don't think we should handle this right now. May revisit later.
@mofojed mofojed requested a review from mattrunyon April 25, 2024 21:19
@mofojed mofojed self-assigned this Apr 25, 2024
- Will fill the contents of the panel if necessary
package.json Outdated Show resolved Hide resolved
Comment on lines 201 to 203
# Something catastrophic happened, log it and close the connection
logger.exception(e)
self._connection.on_close()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an example of something that can cause this? Just want to test it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmm I can't think of a way it could raise an exception right now... but I want to make sure we don't log the error at all. Uncaught exceptions on submit_task are not logged and do not shut down the system: deephaven/deephaven-core#5192
I'll add that note to the comment, this is more just to be safe. Really, the issue above should be fixed and then this should be removed (because the server will just shut down at that point).

Comment on lines +373 to +381
request = self._make_notification(
"documentError",
json.dumps(
{
"message": str(error),
"type": type(error).__name__,
"stack": stack_trace,
"code": ErrorCode.DOCUMENT_ERROR.value,
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be in the JSON schema? I don't think we're using it really, but probably not bad to keep it updated unless you don't think we should use schema checking at some point in the future

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it should be, good call.

Comment on lines 12 to 15
/**
* Component that displays an error message in a textarea so user can scroll and a copy button.
* TODO: Use the one from @deephaven/components when it's merged: https://github.com/deephaven/web-client-ui/pull/1965
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to leave this for review in the web-client-ui PR

If you want to test w/ the component, you can externalize @deephaven/components in vite instead of copying the component into dh.ui. Then just import it from @deephaven/components. It's provided via remote-component.config.ts in app-utils

plugins/ui/src/js/src/widget/WidgetErrorView.tsx Outdated Show resolved Hide resolved
plugins/ui/src/js/src/widget/WidgetErrorView.tsx Outdated Show resolved Hide resolved
plugins/ui/src/js/src/widget/WidgetHandler.tsx Outdated Show resolved Hide resolved
plugins/ui/src/js/src/widget/WidgetHandler.tsx Outdated Show resolved Hide resolved
@mofojed mofojed requested a review from mattrunyon April 26, 2024 18:17
- They're not quite correct yet, but I want to refactor some other things first.
- Now it will just render as an overlay for any panels that are open, rather than closing/re-opening panels
- No longer needed now that we have overlay rendering over existing content
- Now it will check that the error cases are displayed correctly
- Still need the package to be published
"@deephaven/jsapi-bootstrap": "^0.74.0",
"@deephaven/jsapi-components": "^0.74.0",
"@deephaven/chart": "^0.73.0",
"@deephaven/components": "^0.73.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we probably do want to bump these to use the ErrorView from @deephaven/components

@@ -0,0 +1,13 @@
/** A panel that uses the ReactPanelContentOverlayContext and if that content is set, renders it in a view with a partially transparent background */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment needs to go above the component, not at the top of the file

plugins/ui/src/js/src/styles.scss Outdated Show resolved Hide resolved
plugins/ui/src/js/src/widget/ErrorView.tsx Outdated Show resolved Hide resolved
plugins/ui/src/js/src/widget/DocumentHandler.tsx Outdated Show resolved Hide resolved
@mofojed mofojed requested a review from mattrunyon May 9, 2024 14:15
@mattrunyon
Copy link
Contributor

Noticed #85 is also fixed by this PR

The styling is inconsistent between components that didn't render and components that did

Same background color
image

Different background color on the right and darker looking overlay
image

@mofojed
Copy link
Member Author

mofojed commented May 9, 2024

@mattrunyon On the right it is overlaid on top of content, so it appears as a shade. This is akin to when we have a table that doesn't open because of an error, and a table that gets an error, e.g.:
image
...though it looks like the shade there isn't done at all. Looking into it a bit further, seems like we've got different values for all the scrims: https://github.com/search?q=repo%3Adeephaven%2Fweb-client-ui%20black-opacity&type=code

For IrisGrid we use 10% (which I think is incorrect): https://github.com/deephaven/web-client-ui/blob/3de52d6fa0512792c97928f65f0b4b1080da2c49/packages/components/src/LoadingOverlay.scss#L5

For ChartPanel we use 50% (which is probably better): https://github.com/deephaven/web-client-ui/blob/3de52d6fa0512792c97928f65f0b4b1080da2c49/packages/dashboard-core-plugins/src/panels/ChartPanel.scss#L5

And then here I've got 90%.

@dsmmcken Which scrim % should be used in these cases?

@mattrunyon
Copy link
Contributor

In my pictures with and without content, both panels have the same color (look at the bottom of the panels). So I think that the opacity is applied at the wrong element or is not being applied if there's no content.

@mofojed
Copy link
Member Author

mofojed commented May 9, 2024

@dsmmcken here it is with 50%, what do you think?

image

@mofojed
Copy link
Member Author

mofojed commented May 9, 2024

Light theme we may want to use something different rather than black-opacity...:
image

@mofojed
Copy link
Member Author

mofojed commented May 9, 2024

@mattrunyon the error overlays overtop of the content if it exists and that's when a transparency is applied.

@mofojed
Copy link
Member Author

mofojed commented May 9, 2024

Used bg-content instead so it themes correctly, and up'd it to 80%.
image (16)
image (15)

@dsmmcken
Copy link
Contributor

dsmmcken commented May 9, 2024

:shipit:

@mattrunyon
Copy link
Contributor

The error box itself should be more opaque (the red). If you had a more complex component under it, I think it might be too low contrast and too hard to read

@mofojed
Copy link
Member Author

mofojed commented May 10, 2024

A bit of blur would achieve the same thing:
image

@mofojed
Copy link
Member Author

mofojed commented May 10, 2024

@mattrunyon Don approved with the blur.

@mattrunyon
Copy link
Contributor

Ok. I'm still not a fan of the red text on transparent red background. Seems like it's still too low contrast, but I'll defer to Don on this one

Copy link
Contributor

@mattrunyon mattrunyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both light and dark theme with and without content fail the chrome contrast ratio test for accessibility (I checked the contrast ratio on the "ValueError" span w/ dev tools).

That said, it's not worth holding this up since it should be fine in most cases still. And it would be a change in web-client-ui to fix the contrast of ErrorView

@mofojed
Copy link
Member Author

mofojed commented May 10, 2024

@mattrunyon there's a PR for improving error view in web-client-ui: deephaven/web-client-ui#2001

@mofojed mofojed merged commit b23b571 into deephaven:main May 10, 2024
13 checks passed
mofojed added a commit to mofojed/deephaven-plugins that referenced this pull request May 17, 2024
- Reverted package-lock.json to before deephaven#436
- Fixed the jsapi-types stuff, then do an npm install to re-update the package-lock.json
mofojed added a commit that referenced this pull request May 21, 2024
- Reverted package-lock.json to before
#436
- Fixed the jsapi-types stuff, then do an npm install to re-update the
package-lock.json
@mofojed mofojed linked an issue May 28, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants