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

feat(frontend): sets autofocus on select field on desktop #4456

Merged
merged 23 commits into from
Feb 3, 2025

Conversation

BonomoAlessandro
Copy link
Collaborator

@BonomoAlessandro BonomoAlessandro commented Jan 27, 2025

Motivation

If the select token modal of the swap process is opened, the search field should automatically receive focus, but only on desktop. The exact same should happen if the manage list modal is opened.

Changes

  • auto focus search fields on desktop

Tests

before:
image

after:
image

@BonomoAlessandro BonomoAlessandro marked this pull request as ready for review January 27, 2025 13:26
@BonomoAlessandro BonomoAlessandro requested a review from a team as a code owner January 27, 2025 13:26
@BonomoAlessandro BonomoAlessandro changed the title feat(frontend): adds autofocus to InputTextWithAction component feat(frontend): sets autofocus on select field on desktop Jan 27, 2025
@BonomoAlessandro
Copy link
Collaborator Author

@peterpeterparker What do you think about the device.utils.ts class? Do you see a better or cleaner solution than my implementation?

Copy link
Member

@peterpeterparker peterpeterparker left a 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}"]`);
Copy link
Member

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.

Copy link
Collaborator Author

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.

src/frontend/src/lib/utils/device.utils.ts Outdated Show resolved Hide resolved
@@ -0,0 +1,16 @@
import { nonNullish } from '@dfinity/utils';

interface UserAgentData {
Copy link
Member

@peterpeterparker peterpeterparker Jan 27, 2025

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.

src/frontend/src/lib/utils/device.utils.ts Outdated Show resolved Hide resolved
@peterpeterparker
Copy link
Member

peterpeterparker commented Jan 29, 2025

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.

@BonomoAlessandro
Copy link
Collaborator Author

@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 device.utils. You can find it here: #4493

@peterpeterparker
Copy link
Member

peterpeterparker commented Jan 29, 2025

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.

@BonomoAlessandro
Copy link
Collaborator Author

@peterpeterparker I am now using the newest version of the gix-components.

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",
Copy link
Member

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.

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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

Copy link
Member

Choose a reason for hiding this comment

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

Thx!

Copy link
Member

@peterpeterparker peterpeterparker left a 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();
Copy link
Member

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. ;)

@BonomoAlessandro BonomoAlessandro merged commit 0a0d9b5 into main Feb 3, 2025
21 checks passed
@BonomoAlessandro BonomoAlessandro deleted the feature(frontend)/autofocus-search-fields branch February 3, 2025 11:28
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.

2 participants