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

lib: Port us away from simple deprecated Select variant #21356

Merged
merged 13 commits into from
Dec 11, 2024

Conversation

mvollmer
Copy link
Member

@mvollmer mvollmer commented Nov 29, 2024

@mvollmer mvollmer added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Nov 29, 2024
@mvollmer mvollmer force-pushed the lib-simple-select branch 2 times, most recently from 5f566fc to 424c36c Compare December 3, 2024 10:20
@mvollmer mvollmer removed the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 3, 2024
@mvollmer mvollmer marked this pull request as ready for review December 3, 2024 10:46
@mvollmer mvollmer force-pushed the lib-simple-select branch 2 times, most recently from e32a887 to 989b764 Compare December 3, 2024 13:10
@mvollmer
Copy link
Member Author

mvollmer commented Dec 4, 2024

@garrett, how should normal dropdown selects look?

Like this (a):

image

Or like this (b):

image

FormSelect and the deprecated Select that we are still using in many places look like (a). The new simple Select introduced in this PR would look like (b) because of our fix for patternfly/patternfly#6632 in patternfly-5-overrides.scss. With upstream PF5 styling, the new simple Selects would also look like (a).

Since we have traditionally been okay with how FormSelect and the deprecated Select look, I assume for now that the new simple Select should continue to look like them, i.e. like (a).

Consequently, I have narrowed the scope of the "double spacing" bug fix to the dropdowns in the Shell masthead. I think that's the only place where we want it (assuming (a) is the desired look for select dropdowns). Without the bug fix, the masthead dropdowns look uncentered since the large icon on their left doesn't have a margin, while the dropdown icon on the right has one.

@mvollmer mvollmer added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 4, 2024
@mvollmer
Copy link
Member Author

mvollmer commented Dec 4, 2024

The pixel tests and git grep found 2 dropdowns that are affected by our current "double spacing" bug fix: zoom controls and the "Add member" menu of bonds/bridges/etc.

Consequently, they currently look like (b) above, and thus look different from other dropdowns. This PR will change them to look like (a) as a side effect.

@mvollmer
Copy link
Member Author

mvollmer commented Dec 4, 2024

If we decide that dropdown should look like (b) everywhere (which I wouldn't object to at all), then we should do that in one step and change the looks of the deprecated Select and FormSelect in a separate PR and block this one on it.

@mvollmer
Copy link
Member Author

mvollmer commented Dec 4, 2024

@garrett, now about the background color... The non-deprecated MenuToggle that this PR uses for simple Select dropdown has a transparent background in light mode, while the deprecated Select has regular white. This makes a difference when the page background is not also white, like in toolbars:

With deprecated Select:

image

With non-deprecated MenuToggle:

image

Note that the "Filters" SearchInput input group has a white background but the "Pause" button is transparent. As far as I can tell, this is the default PF behavior.

Which should it be?

As with the icon margins, I have made it so that this PR keeps the current look.

@mvollmer mvollmer requested a review from garrett December 4, 2024 12:28
@mvollmer mvollmer removed the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 4, 2024
@mvollmer mvollmer requested a review from jelly December 4, 2024 14:25
@mvollmer mvollmer requested a review from martinpitt December 5, 2024 06:40
@garrett
Copy link
Member

garrett commented Dec 5, 2024

b is definitely incorrect; a looks more correct at a glance

the widgets should all have a white background there, including the secondary button; they need contrast... the text on grey isn't enough contrast, and additionally the grey on the widgets make them look disabled

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! The only actual bug here (I think) is the accidentally dropped isDisabled; plus two questions.

pkg/lib/cockpit-components-simple-select.tsx Show resolved Hide resolved
Comment on lines 64 to 65
const timeFilterParams = {
current: { param: "boot", value: 0 },
Copy link
Member

Choose a reason for hiding this comment

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

Could we somehow allow "any additional junk" in the type declaration of MenuItem, so that we can continue to add these extra fields right in their declaration? and they are passed through event handlers opaquely?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, interesting. I had assumed that SelectOption.value needs to be a string (or number) because that's what the templates use. But it can in fact be "any" value.

The templates use value as a key, and this wont work when value can be any value.

So...I would have to go "back to the drawing board". Have to think about it.

But, I would agree that the changes here in logs.jsx are too large. I wanted to make the use of SimpleSelect trivial, but that has caused risky and confusing changes to the rest of the code. I'll roll that back a bit probably.

Copy link
Member Author

Choose a reason for hiding this comment

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

What about allowing

{ 
  content: _("Current boot"),
  value: { key: "boot", value: 0 },
}

and we use content as the React key?

Copy link
Member

Choose a reason for hiding this comment

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

FTR, I'm completely happy with the values here. Restricting them to strings (or perhaps also numbers) keeps things easy and non-ambiguous. I was just asking if we could merge timeFilterParams into timeFilterOptions by just adding extra param and systemd_value (or similar) keys.

Both value and content are fine for the key, but I think value is a bit cleaner (i.e. the status quo)

Copy link
Member

Choose a reason for hiding this comment

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

In other words, can we declare SimpleSelectMenuOption as content: string, value: string | number, plus "any additional stuff" like [string]: unknown?

If that's difficult/impractical then ignore me. I was just wondering if object types can be partially specified and partially opaque.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done. content can be any React.ReactNode so it can't always be used as a key, so we fall back to the ... index. :-/ But a explicit key in SimpleSelectOption is also supported.

Copy link
Member Author

Choose a reason for hiding this comment

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

In other words, can we declare SimpleSelectMenuOption as content: string, value: string | number, plus "any additional stuff" like [string]: unknown?

Hmm, we could, but I think it's not a good idea. It already has all the options from SelectOption, which inherits from MenuItem, and I think the risk of collision is just too big. For example, both key and value are already taken.

The old code also didn't do this. It didn't have

<SelectOption key='boot' value='-1'>Previous boot</SelectOption>

in it, but constructed it from timeFilterOptions.

Copy link
Member

Choose a reason for hiding this comment

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

I see. I clearly don't understand this enough, and it looks fine - I was just curious. So let's just keep this. Thanks!

pkg/lib/serverTime.js Outdated Show resolved Hide resolved
@mvollmer
Copy link
Member Author

mvollmer commented Dec 5, 2024

b is definitely incorrect; a looks more correct at a glance

Ok, thanks! Then this PR is already correct.

the widgets should all have a white background there, including the secondary button; they need contrast... the text on grey isn't enough contrast, and additionally the grey on the widgets make them look disabled

Right, the this PR is also correct re the background.

I'll fix the button in a separate PR.

Thanks!

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! One more raised eyebrow.

Comment on lines 58 to 61
{ value: { key: "boot", value: 0 }, content: _("Current boot") },
{ value: { key: "boot", value: "-1" }, content: _("Previous boot") },
{ value: { key: "since", value: "-24hours", default: true }, content: _("Last 24 hours") },
{ value: { key: "since", value: "-7days" }, content: _("Last 7 days") },
Copy link
Member

Choose a reason for hiding this comment

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

How are these not duplicate React keys?

I know the old code had this as well, and maybe that's just misleading -- these may not actually be React keys, but a custom value that we use to construct the journalctl argv? But then, the value is being used as the React key And that should be a string, not an object. How does this work?

Copy link
Member Author

Choose a reason for hiding this comment

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

these may not actually be React keys

Correct. The `key`` field of the value object has nothing to do with React. It is used in the URL.

The React key is now content. Or you can specify it explicitly as well, like

{ key: 12, value: { key: "boot", value: 0 }, content: _("Current boot") }

(There was an intermediate version of this PR that had renamed key to param. But I reverted it once it become no longer necessary to reduce changes to the code.)

Copy link
Member Author

@mvollmer mvollmer Dec 10, 2024

Choose a reason for hiding this comment

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

I changed this back to use value as the key and document the need for an explicit key when value isn't suitable.

From 3b857f8b06440bccc8e7979cf686f4e3261ff4df
But not yet for the "checkbox" variant.
So that the SimpleSelect template looks like the deprecated Select
that it is replacing, and like the FormSelect that we are also using.

Instead, fix the dropdown margings in the Shell masthead, to keep them
as they were.
The default is transparent, which would make them look grey in a grey
toolbar for example.  The old deprecated Select had a white background
in those contexts, so let's emulate it.
The linter complains otherwise, since we no longer use it in Cockpit
itself. There are no other external users either, afaics.
@mvollmer mvollmer added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 10, 2024
@mvollmer mvollmer requested a review from martinpitt December 10, 2024 13:01
@martinpitt
Copy link
Member

This pixel change feels like a regression to me, but if that's hard to fix, I don't consider it a blocker. This pixel change is a bug fix and can be accepted into the reference.

martinpitt
martinpitt previously approved these changes Dec 10, 2024
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! As I wrote above, the pixel refs need to be updated. I'm ok with that spacing regression becoming a follow-up, unless you already know how to fix it and it's easy.

Otherwise, code looks nice to me!

Comment on lines +58 to +61
{ key: 1, value: { key: "boot", value: 0 }, content: _("Current boot") },
{ key: 2, value: { key: "boot", value: "-1" }, content: _("Previous boot") },
{ key: 3, value: { key: "since", value: "-24hours", default: true }, content: _("Last 24 hours") },
{ key: 4, value: { key: "since", value: "-7days" }, content: _("Last 7 days") },
Copy link
Member

Choose a reason for hiding this comment

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

Thanks, that avois the confusion around what key is. (A bit weird to use numbers which don't mean anything, but that's fine).

@mvollmer mvollmer removed the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 10, 2024
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! You removed no-test after force-pushing, so nothing ran yet. I triggered the tests.

});

const onToggleClick = () => {
onToggle && onToggle(!isOpen);
Copy link
Contributor

Choose a reason for hiding this comment

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

This added line is not executed by any test.

const _onSelect = (_event: React.MouseEvent<Element, MouseEvent> | undefined, value: unknown) => {
if (value)
onSelect(value);
onToggle && onToggle(true);
Copy link
Contributor

Choose a reason for hiding this comment

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

This added line is not executed by any test.


let content: React.ReactNode = placeholder;
if (toggleContent)
content = toggleContent;
Copy link
Contributor

Choose a reason for hiding this comment

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

This added line is not executed by any test.

Comment on lines +173 to +175
onOpenChange={(isOpen) => {
onToggle && onToggle(isOpen);
setIsOpen(isOpen);
Copy link
Contributor

Choose a reason for hiding this comment

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

These 3 added lines are not executed by any test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants