-
Notifications
You must be signed in to change notification settings - Fork 26
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
feat(frontend): sets autofocus on select field on desktop #4456
feat(frontend): sets autofocus on select field on desktop #4456
Conversation
@peterpeterparker What do you think about the |
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.
-
Can you provide the utility in a separate PR?
-
No tests?
|
||
onMount(() => { | ||
if (autofocus) { | ||
let component = document.querySelector<HTMLInputElement>(`input[name="${name}"]`); |
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.
Is there a particular reason why you're using vanilla JavaScript instead of Svelte here?
If not, could you switch to Svelte? I generally prefer to avoid mixing both approaches, as I'm not sure that it cannot lead to unexpected behavior.
Additionally, this query selector seems optimistic, as it selects any matching element from the root. There seems to be nothing preventing another component from reusing the exact same selector in the future, which could lead to unexpected behavior or malfunctions.
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.
@peterpeterparker yes there is. If i use the svelte bind
, i will get the svelete component Input
from gix-components
, which does not provide an option to set focus. To be able to set the focus, i use the JavaScript to directly access the input
element, allowing me to set the focus.
@@ -0,0 +1,16 @@ | |||
import { nonNullish } from '@dfinity/utils'; | |||
|
|||
interface UserAgentData { |
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.
Is there a typedef (@types/...
) available for this? If not, should we declare the type globally in a .d.ts
file in case it ever become available in NodeJS?
Like declaring it for the navigator
this way you do not have to explicitely declare the types when you use it.
Strictly a question, not a call to action.
Thanks for the clarification. So, why not enhancing the Gix components directly instead of working around in OISY? This feature could be integrated into the design kit, allowing the community and other foundation dapps, like NNS dapp, to benefit from it as well. Alternatively, why not just exposing the HTML input element in the Gix component? The former is probably cleaner and more meaningful but, the later would at least avoid adding a workaround which, without tests (you are going to provide some?), might fail some day. |
@peterpeterparker I also think the cleanest solution would be to enhance the Gix components, but this will take some time. In the meantime, we want to implement a workaround on the OISY side. As you requested in your first comment, i have provided some test cases and created a separate PR for the |
I reviewed and approved #4493, thanks! It was a draft, but since you mentioned it, I guess it was ready. Regarding Gix components, I don't think it takes that much more time, and I believe this workaround, as it is in this PR, should not be implemented this way. Hence, I’m personally not going to approve this PR in this form. |
…ofocus-search-fields
@peterpeterparker I am now using the newest version of the |
package.json
Outdated
@@ -57,7 +57,7 @@ | |||
"@dfinity/candid": "^2.1.2", | |||
"@dfinity/ckbtc": "^3.1.6", | |||
"@dfinity/cketh": "^3.4.3", | |||
"@dfinity/gix-components": "^5.0.0-next-2024-12-10", | |||
"@dfinity/gix-components": "^5.0.0-next-2025-01-31", |
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.
Does this next
of Gix components version contains solely the changes for this PR or does it contains other changes? If the later, it's cleaner I think to provide the upgrade in a dedicated PR. If the former, nvm this comment.
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.
@peterpeterparker This provides all the changes made since december 10th. I will create a separate PR for this
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.
@peterpeterparker I just opened the PR: #4540
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.
Thx!
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.
LGTM, thx
|
||
onMount(() => { | ||
if (autofocus && nonNullish(inputElement)) { | ||
inputElement.focus(); |
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.
Just a note—I assume you tested this after the change in Gix components.
Spontaneously, I would rather use an auto-subscriber, as I'm not sure the reference to the DOM element would always be established when the component is mounted. But I'm probably just being paranoid. ;)
Motivation
If the
select token modal
of theswap
process is opened, the search field should automatically receive focus, but only on desktop. The exact same should happen if themanage list modal
is opened.Changes
Tests
before:
after: