chore(search): added logic to hold search value on escape

Rajdeepc commented 1 month ago

Background

The current implementation uses type="search" on the input element, causing the search value to be cleared whenever the ESC key is pressed. This default behavior is not always desirable.

Objective

To provide an API that allows users to determine whether the search value should be retained when the ESC key is pressed. This will be achieved through a new property holdValueOnEscape.

Implementation Details

Property Introduction: A new Boolean property holdValueOnEscape is introduced. When set to true, the typeattribute of the input element is set to 'text', preventing the default behavior of clearing the input value on ESC.

Default Behavior: By default, holdValueOnEscape is true, ensuring the value is retained when ESC is pressed. Conditionally Setting Type: In the firstUpdated lifecycle method, the type attribute of the input element is conditionally set to 'text' based on the holdValueOnEscape property.

Related issue(s)

-

Motivation and context

How has this been tested?

[ ] Storybook
1. Go here
2. Type something on the Searchbox
3. Press ESC
4. See the value doesn't reset
[ ] Test case 2
1. Go here
2. Do this

Screenshots (if appropriate)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] If my change required a change to the documentation, I have updated the documentation in this pull request.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

github-actions[bot] commented 1 month ago

Branch preview

Visual regression test results

github-actions[bot] commented 1 month ago

Lighthouse scores

Category	Latest (report)	Main (report)	Branch (report)
Performance	0.99	0.99	0.99
Accessibility	1	1	1
Best Practices	1	1	1
SEO	1	0.92	0.92
PWA	1	1	1

What is this?

[Lighthouse](https://github.com/GoogleChrome/lighthouse) scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on main ("Main"). Higher scores are better, but *note that the SEO scores on Netlify URLs are artifically constrained to 0.92.*

Transfer Size

Category	Latest	Main	Branch
Total	222.586 kB	210.736 kB 🏆	210.775 kB
Scripts	54.539 kB	48.482 kB	48.354 kB 🏆
Stylesheet	35.052 kB	30.302 kB 🏆	30.487 kB
Document	5.98 kB	5.347 kB	5.31 kB 🏆
Font	127.015 kB	126.605 kB 🏆	126.624 kB

Request Count

Category	Latest	Main	Branch
Total	45	45	45
Scripts	37	37	37
Stylesheet	5	5	5
Document	1	1	1
Font	2	2	2

github-actions[bot] commented 1 month ago

Tachometer results

Chrome

## search [_permalink_](#user-content-search) ### test-basic | Version | Bytes | Avg Time | vs remote | vs branch | |---|---|---|---|---| | npm latest | 472 kB | 39.27ms - 39.99ms | - | faster ✔
4% - 6%
1.64ms - 2.67ms | | branch | 459 kB | 41.42ms - 42.15ms | slower ❌
4% - 7%
1.64ms - 2.67ms | - |

Firefox

## search [_permalink_](#user-content-search) ### test-basic | Version | Bytes | Avg Time | vs remote | vs branch | |---|---|---|---|---| | npm latest | 472 kB | 72.02ms - 78.18ms | - | unsure 🔍
-8% - +1%
-6.57ms - +0.97ms | | branch | 459 kB | 75.71ms - 80.09ms | unsure 🔍
-1% - +9%
-0.97ms - +6.57ms | - |

adobe / spectrum-web-components