-
Notifications
You must be signed in to change notification settings - Fork 945
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: ErrorWidget as fallback when widgets models or views fail. #2960
base: main
Are you sure you want to change the base?
Feat: ErrorWidget as fallback when widgets models or views fail. #2960
Conversation
This makes sure that we always render something, with a descriptive error message. This makes is easier for users to diagnose or report issues.
This replaces voila-dashboards/voila#667 but is a better version because we can distinguish between loading models and views. |
So previously we used to use the various other mimetypes in the bundle to present an error message (but we stopped doing that?). Would you mind mentioning why this is better? |
I am really interested in this. Was it really what was happening? I feel like the widget mimetype was always rendered, only that this mimetype was showing |
Context in #2007. We seemed to agree then that the best long term solution was "a short HTML entry with a link to an entry in the docs describing the possible causes of seeing the message". Doing something smarter on the JS side might also be a good thing, but I think there is also value in having a shared/similar way of doing things for various different errors that can occur. I.e. I don't think this PR will solve the error message if the user forgot to install the jupyter widget manager (or the install is broken). tl;dr: not opposed to this, but if another solution solves more problems, we should at least compare them. |
Ugh, it seems the notebook issue that was preventing us from using html mimetype is still open: jupyter/notebook#2980 Xref: #2024 that is tracking the followup to that. |
I would like to get this in for 8.0 if possible. |
moduleVersion | ||
) as Promise<typeof WidgetModel>; | ||
await promise; | ||
return promise; |
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.
Why do you need to await the promise before returning it?
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.
to catch a possible exception
|
||
export class ErrorWidgetView extends DOMWidgetView { | ||
render() { | ||
console.log('render'); |
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.
Leftover?
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.
correct
@maartenbreddels is it supposed to work with classical notebook? It prints:
|
I think I have tested this, is this the js console? |
No, the cell output. |
That should be exactly what it does, or do you refer to the short stack trace? |
Yes, I was wondering why we don't have the same stack trace as in jlab. |
might be due to the transpiling target, I think in the notebook we still use something older (ES5?) and we lose the stack trace, but not 100% sure. |
OK, thanks. |
We're pushing forward to ipywidgets 8. Is there someone that wants to either champion this for 8.0 very soon, or can we move it to 8.1? |
Moving to 8.1 since a champion has not come forth. |
Hello @maartenbreddels, I'm trying to finish this PR. How do you think about this behavior of failback widget? ipy.mp4 |
This makes sure that we always render something, with a descriptive
error message. This makes it easier for users to diagnose or report
issues.
JupyterLab screenshot:
Note that in all cases, the Button and Hbox are rendered.