-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Embeddables] Update EmbeddablePanel
component to trigger edit panel action on error click
#140205
Conversation
Pinging @elastic/kibana-app-services (Team:AppServicesUx) |
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
@dokmic: Would you mind adding some screenshots or a short gif/video of the changes? Thanks! |
13acb6b
to
7fd7b1c
Compare
@MichaelMarcialis I've updated the summary to show a video. Would you mind taking another look? |
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 adding that video, @dokmic. I've added a couple of questions and comments for your review below. Let me know if you have any questions.
<EuiPanel | ||
element="div" | ||
className="embPanel__content embPanel__content--error" | ||
color="transparent" | ||
paddingSize="none" | ||
data-test-subj="embeddableError" | ||
panelRef={ref} | ||
role={isEditable ? 'button' : undefined} | ||
aria-label={isEditable ? ariaLabel : undefined} | ||
onClick={handleErrorClick} | ||
/> |
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.
Rather than making a clickable EuiPanel
, would it be better to use an EuiEmptyPrompt
with an EuiButton
in the actions
prop (see examples in EUI docs)? I imagine that a dedicated button that notifies the user that they will be taken to edit the erroneous visualization would be a more user-friendly experience. Thoughts?
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.
@MichaelMarcialis I've checked the component and the example. I don't think it is applicable in our case:
- The panel here is just a dummy element we use as a placeholder for the UI -- embeddable widgets may render their custom error component. So that we cannot place a button here as it will not be shown in most of the cases.
- This change introduces a generic click handler and doesn't touch any UI.
- The UI present in the video comes from the Visualizations plugin, and it's made in a way to look similar to the error message from the Lens plugin.
- If we would like to change the way it looks, we should create a separate issue that will request updates of the error appearance in three different places at the same time: Lens, Visualizations, and generic Embeddables.
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 that explanation, @dokmic. Just to be sure I'm understanding, you're saying that EmbeddablePanelError
is a placeholder that can be swapped out with a custom error component, correct? Is the swapping out with a custom error component required? Or is it optional, leaving the possibility for this "placeholder" error message to show instead?
If the swapping out of the EmbeddablePanelError
component is optional (leaving the possibility for this "placeholder" error panel to be shown to users), I'm inclined to maintain my suggestion that we should instead utilize EuiEmptyPrompt
here (with a conditional EuiButton
that takes users to edit the visualization). Visually, I believe EuiEmptyPrompt
can be styled to look the same as the error message shown in your example (for the sake of consistency with other error messages), just with the addition of the button for better usability.
Let me know if that makes sense or if I'm misunderstanding anything. CCing @flash1293, in case he has any thoughts.
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.
Not holding this opinion strongly but I expected to use the context menu for this - click the cogwheel and select the edit action from there.
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.
EmbeddablePanelError
is a placeholder that can be swapped out with a custom error component, correct? Is the swapping out with a custom error component required?
Yes, that's correct. It is optional but is overridden in majority of the places.
If the swapping out of the
EmbeddablePanelError
component is optional (leaving the possibility for this "placeholder" error panel to be shown to users), I'm inclined to maintain my suggestion that we should instead utilizeEuiEmptyPrompt
here (with a conditionalEuiButton
that takes users to edit the visualization).
I've checked the code once again, and the change seems impossible at the moment without a significant refactoring. The problem is that we have some internal service to open the panel for edit. It would be tricky to initialize that from Lens or Visualizations. The best solution is to get rid of the custom error components that look similar and use the fallback. But that should be done separately as it requires more work than the original issue and involves more parties.
Is that okay if I create a separate ticket to address that?
.embPanel__content--error { | ||
&:hover { | ||
box-shadow: none; | ||
transform: 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.
If taking my suggestion to use an EuiEmptyPrompt
with EuiButton
, these styles will likely no longer be necessary.
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.
I've checked the code once again, and the change seems impossible at the moment without a significant refactoring. The problem is that we have some internal service to open the panel for edit. It would be tricky to initialize that from Lens or Visualizations. The best solution is to get rid of the custom error components that look similar and use the fallback. But that should be done separately as it requires more work than the original issue and involves more parties.
Is that okay if I create a separate ticket to address that?
Thanks, @dokmic. If ya'll are willing to create that separate issue to help implement the above design suggestions, that sounds like a reasonable approach to me. Approving now so I don't hold you up further.
7fd7b1c
to
56789e4
Compare
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Page load bundle
History
To update your PR or re-run it, just comment with: |
I've created #141676 to address the UI updates as it was discussed above. |
… action on error click (elastic#140205)
Summary
Resolves #138608.
Embeddable.Error.Click.mov
Checklist