-
Notifications
You must be signed in to change notification settings - Fork 1.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
[dashboard] Allow options on ws start (2/2) #15389
Conversation
e56ef18
to
d016608
Compare
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.3 |
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.4 |
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.5 |
d016608
to
c19a090
Compare
18c07ed
to
bfefd13
Compare
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-se-start-with-options-2.9 |
Got some minutes in front of the computer. Taking a quick look! 👀 /werft run with-clean-slate-deployment 👍 started the job as gitpod-build-se-start-with-options-2.10 |
03ba412
to
d62e2c0
Compare
The filtering is based on
Some IDEs have the same version for
Yes, it's just the preview env configuration that is different to prod (not really helpful, though).
Yes, also the ESC and cursor keys aren't working on the workspaceClass element. It is because it doesn't have a search input field. cc @selfcontained any idea how this could be fixed? |
f1fcb4e
to
934fda5
Compare
I've fixed those issues, by moving the search input out of the view 😇 . |
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.18 |
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.
Most of the comments are non-blocking. I did notice some weird behavior trying to close expanded dropdowns (video included) that would be nice to fix.
Generally I had a comment about the level of effort it might take to make a component like this accessible, and how we might want to think about that.
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.19 |
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-se-start-with-options-2.20 |
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-se-start-with-options-2.22 |
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-se-start-with-options-2.23 |
934fda5
to
acea6bf
Compare
acea6bf
to
699e02b
Compare
I think this would be very useful to have inside of https://github.com/gitpod-io/browser-extension replacing the Gitpod direct workspace opening button with a dropdown for all of the options; that's at least how I mainly open my workspaces. |
My current plan is to enhance the create workspace URL with a parameter that opens let's users review and change those options on before workspace creation. |
/werft run 👍 started the job as gitpod-build-se-start-with-options-2.26 |
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 feels much better, thank you! I left a few non-blocking comments/ideas on other improvements we could make or consider. I don't think they have to hold it up though, and we could iterate on it as we go.
onSelectionChange: (id: string) => void; | ||
} | ||
|
||
export const DropDown2: FunctionComponent<DropDown2Props> = (props) => { |
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.
Non-blocking - but I think it would be helpful in the future to have a better name for this component to help explain what it's intended for, or know when to use this vs. Dropdown
. I don't have any good suggestions though, but thought I'd mention it in case you had any ideas.
useEffect(() => { | ||
setSearch(""); | ||
if (showDropDown && selectedElementTemp) { | ||
document.getElementById(selectedElementTemp)?.scrollIntoView({ behavior: "smooth", block: "nearest" }); |
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 is a non-blocking comment, but something to maybe think about as a way to improve the UX of this component. While this behavior is nice in that it helps show a selected option - it feels a bit disorienting to watch a long list scroll when you open the dropdown. It also adds an additional step if you just wanted to type to filter after you expanded the list (now the search input is not focused and out of view).
A more common UX pattern for interfaces like this I think that can fit well would be to have the selected component always show up on top of the list of options, and then the search input can stay focused when the dropdown opens, making it easy to type, and you also see the selected option.
Another option could be having the search input not in the scrollable container, and stay pinned so that only the options scroll. Either way, I don't think this is a blocker, just some suggestions to consider if we want to improve it a bit.
if (showDropDown && e.key === "ArrowDown") { | ||
e.preventDefault(); | ||
let idx = filteredOptions.findIndex((e) => e.id === selectedElementTemp); | ||
while (idx++ < filteredOptions.length - 1) { |
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.
It took me awhile to understand why we needed a loop here. I think it's so that we select the next "selectable" option, since not all options are selectable. If I'm understanding that correctly, maybe a comment to help future-us understand it a bit would be helpful?
<li | ||
key={element.id} | ||
id={element.id} | ||
tabIndex={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.
I wonder if we want to avoid having these option elements be tab indexed. As it is, once the container is open, tabbing doesn't proceed to the next "input" in the view, i.e. the next dropdown in this case, but shifts the selected option to the next one. A normal select in the browser will only use arrow keys for navigating the selected option, while tab will let you move on to the next "input".
onSelected(element.id); | ||
} | ||
}} | ||
onMouseOver={() => setFocussedElement(element.id)} |
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 part felt a little weird to me, having the mouseover select the option rather than requiring a click or keyboard navigation to select it. It also seems to be making the scroll container do a bit of a jittery scroll as you mouse over options at the edge of what's currently in view.
Description
Updates the Open Workspace Modal to allow specifying the workspace class and editor.
Related Issue(s)
Fixes #15287
How to test
Use the Open workspace dialog on the preview's /workspaces view
Release Notes
Documentation
Werft options:
If enabled this will build
install/preview
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh