-
Notifications
You must be signed in to change notification settings - Fork 4.4k
[VAULT-35469] UI: navigate to namespace on enter/return #30372
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
[VAULT-35469] UI: navigate to namespace on enter/return #30372
Conversation
CI Results: |
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.
Pull Request Overview
This PR enhances the namespace picker by enabling direct navigation via the Enter/Return key when a valid namespace is entered. Key changes include:
- Adding tests for input focus and navigation behavior in both integration and acceptance suites.
- Refactoring the component actions to better handle search input, key events, and list refresh operations.
- Updating selector usage to consistently reference the defined searchInput selector.
Reviewed Changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.
File | Description |
---|---|
ui/tests/integration/components/namespace-picker-test.js | Updates tests to use the searchInput selector and adds a focus test |
ui/tests/helpers/namespace-picker.js | Adds a new selector for the search input |
ui/tests/acceptance/enterprise-namespaces-test.js | Adds tests for input focus and navigation on Enter key press |
ui/app/components/namespace-picker.js | Refactors actions to support Enter key navigation and input refresh |
Files not reviewed (1)
- ui/app/components/namespace-picker.hbs: Language not supported
Comments suppressed due to low confidence (1)
ui/tests/acceptance/enterprise-namespaces-test.js:67
- Consider using the currenturl("") helper from '@ember/test-helpers' for asserting navigation outcomes instead of accessing the router service directly for consistency with other tests.
assert.strictEqual( this.owner.lookup('service:router').currentURL, '/vault/dashboard?namespace=beep%2Fboop', 'Navigates to the correct namespace when Enter is pressed' );
7f2606c
to
678c2ef
Compare
c7e51a5
to
3f0a323
Compare
Build Results: |
@@ -30,6 +31,7 @@ export default class NamespacePicker extends Component { | |||
|
|||
@tracked allNamespaces = []; | |||
@tracked searchInput = ''; | |||
@tracked searchInputHelpText = 'Enter a full path in the search bar and hit ↵ key to navigate faster.'; |
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 an a11y question that I'm honestly not sure of the answer. But I know for screen readers it might try to say the back key and can't because it's a symbol. Maybe check with design on the use of this here?
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.
Good catch!! I'll ask design, thank you!!
options.unshift({ id: 'root', path: '', label: 'root' }); | ||
} | ||
|
||
return options; | ||
} | ||
|
||
get hasSearchInput() { | ||
return this.searchInput?.trim().length > 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'm curious why we need to trim the input here? Do we expect people will enter a space only?
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 more just due diligence/habit. I can't tell you how many times I've thought, "a user would never..." only to be immediately proved wrong lol
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.
Solid call out. And a note for posterity, I checked with the API — we do not allow spaces in namespaces, so there is no chance someone could intentionally want to search a word with a space at the end.
@@ -3,6 +3,13 @@ | |||
* SPDX-License-Identifier: BUSL-1.1 | |||
*/ | |||
|
|||
/* | |||
* DEPRCATED (see: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode). |
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.
Good catch, if we don't already can you make a ticket for this and throw it in our backlog or add to sustaining?
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.
our copilot prompt caught this one!! 🎉 I'll create a ticket and add it to sustaining
@@ -28,51 +38,83 @@ module('Acceptance | Enterprise | namespaces', function (hooks) { | |||
fetchSpy.restore(); | |||
}); | |||
|
|||
test('it focuses the search input field when the component is loaded', async function (assert) { | |||
assert.expect(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.
This is probably a good thing to add to our rules document, but you really only need assert.expect
if there's a chance the test could run without all the assertions being hit. This is common when using mirage when you have an assertion inside a this.server.x because if that network request doesn't get hit neither will the assertion and the test could still pass.
In the cases here it appears that all the assertions will be hit, and so we don't need to have the .expect catch.
let me know if that does/doesn't make sense.
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.
ah okay that's good to know - I thought it as a fail-safe pattern because I've seen it a lot, but that makes sense!
{{on "input" this.onSearchInput}} | ||
{{did-insert this.focusSearchInput}} |
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'm guessing that the focus on opening this was previous behavior? If so, I can't say we always did focus things according to best a11y practices. Looking at the hds pattens on focus, it might be good to review that we can indeed follow them.
If this was old behavior, maybe we should revisit this with Design's input (not blocking here, but come back with a ticket after discussion)? What are your thoughts?
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 for linking this! previously there was no focus behavior set because there was no search input field in the namespace picker. but it feels natural that, when the user opens the namespace picker, focus should default to the search input. it potentially reduces clicks, allowing the user to immediately type in the search or tab to the namespaces in the list. I don't see anything re: this specific use case outlined in the a11y: focus management section, but it also doesn't seem to contradict the patterns outlined.
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.
Nothing blocking, one question about focus on insert, but if that needs to be addressed we can do it in another ticket.
f53662c
into
VAULT-34216/namespace-picker-feature-branch
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
* [VAULT-35469] UI: navigate to namespace on enter/return * address github copilot suggestions * address PR comments
Description
What does this PR do?
Demo
Screen.Recording.2025-04-24.at.5.11.08.PM.mov
TODO only if you're a HashiCorp employee
backport/
label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x
, but older release branches will bebackport/ent/x.x.x+ent
.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.