-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
4658e3e
to
93eaba8
Compare
93eaba8
to
c19dbe7
Compare
5f566fc
to
424c36c
Compare
e32a887
to
989b764
Compare
@garrett, how should normal dropdown selects look? Like this (a): Or like this (b): 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. |
989b764
to
0b9fea2
Compare
The pixel tests and 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. |
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. |
0b9fea2
to
93dc76c
Compare
@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: With non-deprecated MenuToggle: 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. |
93dc76c
to
5acb60f
Compare
5acb60f
to
8760214
Compare
8760214
to
dd310b3
Compare
eff00ed
to
5aa781c
Compare
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 |
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! The only actual bug here (I think) is the accidentally dropped isDisabled
; plus two questions.
pkg/systemd/logs.jsx
Outdated
const timeFilterParams = { | ||
current: { param: "boot", value: 0 }, |
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.
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?
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.
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.
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.
What about allowing
{
content: _("Current boot"),
value: { key: "boot", value: 0 },
}
and we use content
as the React key?
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.
FTR, I'm completely happy with the value
s 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)
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.
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.
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.
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.
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.
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.
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 see. I clearly don't understand this enough, and it looks fine - I was just curious. So let's just keep this. Thanks!
5aa781c
to
f15aa5d
Compare
Ok, thanks! Then this PR is already correct.
Right, the this PR is also correct re the background. I'll fix the button in a separate PR. Thanks! |
f15aa5d
to
2708fa2
Compare
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! One more raised eyebrow.
pkg/systemd/logs.jsx
Outdated
{ 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") }, |
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.
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?
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.
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.)
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 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.
…rity OSesWithoutTracer is a list of globs.
2708fa2
to
07bf0df
Compare
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. |
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! 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!
{ 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") }, |
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, that avois the confusion around what key
is. (A bit weird to use numbers which don't mean anything, but that's fine).
db174a3
to
c948cea
Compare
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! You removed no-test after force-pushing, so nothing ran yet. I triggered the tests.
}); | ||
|
||
const onToggleClick = () => { | ||
onToggle && onToggle(!isOpen); |
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.
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); |
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.
This added line is not executed by any test.
|
||
let content: React.ReactNode = placeholder; | ||
if (toggleContent) | ||
content = toggleContent; |
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.
This added line is not executed by any test.
onOpenChange={(isOpen) => { | ||
onToggle && onToggle(isOpen); | ||
setIsOpen(isOpen); |
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.
These 3 added lines are not executed by any test.
Pixel differences: https://github.com/cockpit-project/pixel-test-reference/compare/1f17d8f6d2b39be2c9f19771004fe27c52c1bbce..baa39edeb94890093b3af6bc2e6802279e6d60eb
I think all count as bug fixes.