-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Decouple control fixed width and auto size settings #131769
[Controls] Decouple control fixed width and auto size settings #131769
Conversation
Pinging @elastic/kibana-presentation (Team:Presentation) |
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.
A few questions/suggestions about possible behaviour changes - specifically, whether or not creating a new control should impact the default size. Could be tackled as part of this PR, or I could do it as part of my PR for removing the "Set all sizes to default" checkbox - either is good for me :)
@@ -84,6 +87,7 @@ export const ControlEditor = ({ | |||
const [defaultTitle, setDefaultTitle] = useState<string>(); | |||
const [currentTitle, setCurrentTitle] = useState(title); | |||
const [currentWidth, setCurrentWidth] = useState(width); | |||
const [currentGrow, setCurrentGrow] = useState(true); |
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 think this should probably default to the defaultControlGrow
rather than just true
.
const [currentGrow, setCurrentGrow] = useState(true); | |
const [currentGrow, setCurrentGrow] = useState(defaultControlGrow); |
@@ -83,6 +85,7 @@ export const CreateControlButton = ({ | |||
width={defaultControlWidth ?? DEFAULT_CONTROL_WIDTH} | |||
updateTitle={(newTitle) => (inputToReturn.title = newTitle)} | |||
updateWidth={updateDefaultWidth} | |||
updateGrow={updateDefaultGrow} |
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 don't think we necessarily want to remember this setting between controls, right? From my understanding of this, we should only remember the default control size, which is managed exclusively through the control group settings flyout. Therefore, when creating a new control, the size options should default to this - but changing them when creating a new control and/or editing an existing control should not impact the default size.
Here is a video to show what I mean when I say that creating a new control impacts the default (which, in my opinion, is a bit confusing):
2022-05-09_DecoupleBug2.mp4
I think this is actually the same behaviour we had for control width before this change, which I'm honestly surprised wasn't caught before! Perhaps @andreadelrio could provide some input here, just in case this is actually the desired behaviour :)
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.
Edit: I took care of this as part of my PR for removing the "Set all sizes to default" checkbox (specifically in 0696a71) - here's a video of the new behaviour:
2022-05-09_ManageDefaultViaSettings.mp4
Personally, this new way of managing control sizes is much clearer to me - basically, adding a new control will not impact the default size in any way, only the "Control group settings" flyout will do that. Combined with my PR which introduces a modal that confirms whether or not the new default should be applied to existing controls when modified in the control group settings, I think it's a lot more straight forward! Obviously, this would need some discussion/agreement from everybody, though (especially @andreadelrio and @teresaalvarezsoler)
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.
Just confirming here that the behaviour of "setting the size of the control during control creation sets the default size" was something that happened because I implemented the size check buttons and wanted to store the last used size before I implemented the default size picker in the settings menu, then forgot to remove the original behaviour. So it was indeed the default behaviour before this PR.
I agree that we should separate the two, especially because the default size is saved into the dashboard saved object part of the control group input. So only changing the default size via the settings should actually change 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.
As we discussed in the controls sync, I've now removed all width/expand settings from the group controls since they were causing a bit of confusion.
I'm preserving the behavior that Hannah and Devon were describing where we store the selected width and expand settings on their last control and using those settings as the default when creating new controls. These settings will however revert back to the default medium
width and expand true
settings if you refresh or navigate away from the dashboard you were adding controls to.
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 think this is a cool improvement! I do have some concerns about the label of the setting because if the toggle is off users are actually setting a minimum width
? so I wonder if that would lead to confusion. I think for sure we need to add some help text to this setting. I suggest we add an info icon either next to the label or next to the toggle's text (like the former will work better). There we can explain how this setting works (minimum width, how the toggle changes the behavior, etc).
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.
Caught a bug that I thought belonged in main but it actually belongs here, so added a second review - sorry about that! Should have double checked 😄
@@ -211,6 +214,23 @@ export const ControlEditor = ({ | |||
{ControlGroupStrings.manageControl.getCancelTitle()} | |||
</EuiButtonEmpty> | |||
</EuiFlexItem> | |||
<EuiFlexItem grow /> | |||
<EuiFlexItem grow={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.
Talked with Andrea about this after I logged the following bug and she mentioned that you guys agreed to keep the delete button in its original place - I assume this was left in by accident? Will close the bug - didn't realize it was caused by this code, haha! Oops 😆 But yeah, we should move the "Delete" button back to its original place.
…le-size-and-stretch
@andreadelrio How does this look for the info tooltip next to the @KOTungseth Any edits for the copy here? |
Do folks think it's worth changing the label of the |
I like that! Then we could possibly also make the tooltip show up only when that toggle is set to |
I had considered this but I don't think we should be changing the labels of fields, it would make the form not look as clean. What we could alternatively do is change the label permanently to |
…le-size-and-stretch
@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.
Tested it with the new changes - works great!! 👍
@@ -54,6 +57,21 @@ $controlMinWidth: $euiSize * 14; | |||
cursor: grabbing; | |||
} | |||
} | |||
|
|||
@media only screen and (max-width: 767px) { |
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.
@media only screen and (max-width: 767px) { | |
@include euiBreakpoint('xs', 's', 'm') { |
I believe this is the EUI way to achieve this
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 succeeded, but was flakyFailed CI StepsTest Failures
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
Summary
Closes #129672.
Closes #130702.
This splits up the auto size setting from the rest of the fixed width options, i.e. small, medium, and large. With the two separate sittings, setting a width and checking the switch to expand the control will result in the selected width acting as the minimum width of the control.
Create new control/edit existing control
Control group settings
CheckingSet all widths to default
will set all widths to the default width and grow setting for now until we remove it for #130702.We've decided to remove all of the width settings from the control group settings. Instead of allowing the user to set their default width and expand settings, we will just cache the settings from their last created control and use those settings as the default for subsequent controls.
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers