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
[Controls] Add Fatal Error Handling #133579
[Controls] Add Fatal Error Handling #133579
Conversation
@elasticmachine merge upstream |
@andreadelrio, this may need a styling once-over. I've added a new |
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.
Tested locally + code review - everything works great from a behaviour perspective! Tested both deleting just the data view and deleting the entire index.
This is more of a question for @andreadelrio I think, but the error embeddable doesn't display nicely on small
or medium
sized controls where "Expand width" is set to false
- it only shows properly on large
controls:
Perhaps we could display a shortened version of the error in these cases, with the full error being displayed via popover or something? Or, at the very least, I think that we should ensure that the alert
icon is always visible, since the above small
and medium
views only show part of data view ID, which doesn't really make it clear that an error occurred.
const node = this.compact ? ( | ||
<EuiFlexGroup | ||
style={{ height: '100%', whiteSpace: 'nowrap' }} | ||
gutterSize="none" |
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.
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.
@Heenawter, you really caught how little attention I put into the design of this hahah!
I decided to cut my time fiddling with CSS short, but I'm hoping that @andreadelrio can take a look and fix some things I wasn't able to get to:
- I couldn't change the error background color to white - for some reason the
background-color
rule is disabled, but only in error cases. - Using any gutter size shifts the EuiFlexGroup content upwards, because it adds a negative margin. You can see this even in the XS size in the screenshot above, it isn't exactly centered anymore. Is there something that the flex group needs to be wrapped in to avoid this?
- I attempted to wrap the error text Markdown in a box that would use
text-overflow:elipsis
, but it didn't apply at all. I'm wondering if the markdown component comes with its own styling that overrides that.
Overall, this is a weird case, because the actual error text includes a link which needs to be rendered as markdown. I honestly wonder if we could just have a generic a fatal error has occured
message on the control itself with a tooltip that shows the full message... Even then, the hyperlink wouldn't be created so the error message would look pretty bad, including all the markdown code in a popover hah.
|
@andreadelrio, I've disabled editing when the control is in a fatal error state, because these are technically un-recoverable errors, which replace the Control with an The wording here actually can't be modified without changing it everywhere, because this is unfortunately the actual error text that the data views service I was thinking of a tooltip, but if we used a popover, we could actually potentially render the markdown correctly on the inside of the popover, that's a good idea as long as you think the UX is okay. So maybe the condensed error would show like this: And on click we render markdown inside a popover |
I see! thanks for all the context.
I like this! The reason I was suggesting a popover instead of a tooltip is to allow for the inclusion of a click action (which is not possible when using a tooltip). I think a simple popover (no footer, no title) would work here. If possible, I would like for us to add "Learn more" at the end of the error text. We can show it only for non-small/medium controls if that works better. Just to account for the possibility that users might not know this error text is clickable and to let them know we're trying to provide them more info so they can recover from the error. |
Also, @Heenawter you're developing what we call an eagle eye for design. Very useful to have! |
[Controls] Improve fatal error message styling
I'd ask that you get the @elastic/ux-writers involved on this PR. At quick glance "Fatal" seems like extremely dangerous language. As a quick option I would just put "Can't find data view" as the main input text. |
That is true - Fatal is a pretty extreme word to use. We can't use the actual error text as the main input text because the error could be anything and it could include any amount of markdown, which would potentially make it too large for this small space - hence the popover. Maybe we just say @KOTungseth, I'm open to any suggestion! |
Hi @ThomThomson, Just a general note about error messages, the most important things are to A. let them know what went wrong and B. tell them what they can do about it. So what do we want them to do with a generic error? Try again? Contact support? |
@kellyemurphy, that latest image is a little confusing - it's actually a dashboard, with 2 Controls and one Panel. All three of these things are in an error state, so that is the cause of the repetition. I'm absolutely open to wording suggestions here. Basically we need one generic error message that fits in a small space and would prompt the user to click on it in order to see the actual error text. It would be the actual error text inside the popover which would let them know what went wrong, and also tell them how to fix it. |
Here is a clearer picture of what one of these error controls looks like after the design PR by @andreadelrio. Hopefully that makes this a little clearer. The generic part is at the top, and the part that gives the real error and instructions on how to fix it is in the popover at the bottom. |
Ok, so where does the For phrasing, I'd recommend:
or
And then inside, it would say |
The |
Maybe we can shorten it a bit:
|
@gchaps, the text there is actually coming from the error message itself, we could definitely change it to be shorter, but that is outside of the scope of this PR. |
@elasticmachine merge upstream |
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.
Thanks for making all those updates. Design LGTM.
error: Error | string, | ||
input: EmbeddableInput, | ||
parent?: IContainer, | ||
private compact: boolean = false |
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.
Can we have a unit test (snapshot) to cover the new param?
…Thomson/kibana into controls/fatalErrorHandling
@elasticmachine merge upstream |
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.
LGTM
💚 Build SucceededMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Canvas Sharable Runtime
Page load bundle
History
To update your PR or re-run it, just comment with: |
* Add fatal error handling to Controls Co-authored-by: andreadelrio <andrea.delrio@elastic.co> (cherry picked from commit 7757dbc)
Fixes #129906
Summary
Adds simple fatal error handling to the control wrappers, which is similar to how the embeddable frame handles it.
This PR also changes the Options List and Range Sliders to catch and throw errors properly when their data views are missing.