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

[Controls] Decouple control fixed width and auto size settings #131769

Merged
merged 18 commits into from
May 17, 2022

Conversation

cqliu1
Copy link
Contributor

@cqliu1 cqliu1 commented May 6, 2022

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

Screen Shot 2022-05-06 at 1 21 38 PM

Control group settings

Screen Shot 2022-05-16 at 10 42 17 AM

Checking Set 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:

Risk Probability Severity Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space. Low High Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. High Low Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled. Medium High Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

@cqliu1 cqliu1 added Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas loe:medium Medium Level of Effort release_note:skip Skip the PR/issue when compiling release notes impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. v8.3.0 labels May 6, 2022
@cqliu1 cqliu1 requested review from a team as code owners May 6, 2022 20:53
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

Copy link
Contributor

@Heenawter Heenawter left a 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);
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 should probably default to the defaultControlGrow rather than just true.

Suggested change
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}
Copy link
Contributor

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 :)

Copy link
Contributor

@Heenawter Heenawter May 9, 2022

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)

Copy link
Contributor

@ThomThomson ThomThomson May 16, 2022

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Screen Shot 2022-05-16 at 10 42 17 AM

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.

Copy link
Contributor

@andreadelrio andreadelrio left a 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).

Copy link
Contributor

@Heenawter Heenawter left a 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}>
Copy link
Contributor

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.

@cqliu1
Copy link
Contributor Author

cqliu1 commented May 11, 2022

@andreadelrio How does this look for the info tooltip next to the Control width label? This will be visible in both the create control flyout and the edit control flyout.

Screen Shot 2022-05-11 at 12 26 36 PM

@KOTungseth Any edits for the copy here?

@ThomThomson
Copy link
Contributor

ThomThomson commented May 11, 2022

Do folks think it's worth changing the label of the Control width setting to Minimum control width when the Expand width to fit available space setting is turned on?

@Heenawter
Copy link
Contributor

Do folks think it's worth changing the label of the Control width setting to Minimum control width when the Expand width to fit available space setting is turned on?

I like that! Then we could possibly also make the tooltip show up only when that toggle is set to true, since the text isn't applicable to when it's false 👍

@andreadelrio
Copy link
Contributor

Do folks think it's worth changing the label of the Control width setting to Minimum control width when the Expand width to fit available space setting is turned on?

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 Minimum width and then move the question icon to the right of the toggle.

@cqliu1
Copy link
Contributor Author

cqliu1 commented May 16, 2022

@elasticmachine merge upstream

Copy link
Contributor

@Heenawter Heenawter left a 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) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
@media only screen and (max-width: 767px) {
@include euiBreakpoint('xs', 's', 'm') {

I believe this is the EUI way to achieve this

@andreadelrio andreadelrio self-requested a review May 17, 2022 15:46
Copy link
Contributor

@andreadelrio andreadelrio left a comment

Choose a reason for hiding this comment

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

LGTM 🎉

@cqliu1 cqliu1 enabled auto-merge (squash) May 17, 2022 16:15
@cqliu1 cqliu1 disabled auto-merge May 17, 2022 16:37
@cqliu1 cqliu1 enabled auto-merge (squash) May 17, 2022 18:09
@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #32 / alerting api integration spaces only Alerting bulkEdit should return mapped params after bulk edit

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
controls 204 207 +3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
controls 420.8KB 423.3KB +2.5KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
controls 31.8KB 31.8KB -57.0B
Unknown metric groups

API count

id before after diff
controls 210 213 +3

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@cqliu1 cqliu1 merged commit 6375d90 into elastic:main May 17, 2022
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Dashboard Dashboard related features Feature:Input Control Input controls visualization impact:high Addressing this issue will have a high level of impact on the quality/strength of our product. loe:medium Medium Level of Effort release_note:skip Skip the PR/issue when compiling release notes Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.3.0
Projects
None yet
7 participants