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: Add Search Field component #892

Merged
merged 23 commits into from
Dec 8, 2023
Merged

Conversation

alimpens
Copy link
Contributor

@alimpens alimpens commented Dec 6, 2023

To discuss:

  • The 'clear'-button currently uses native functionality, which only works in Chromium browsers (Chrome, Edge), not in Firefox for example. Is this functionality important enough to implement custom functionality for this?

Out of scope:

  • Search Field without a button (for instant search result pages, see https://onderzoek.amsterdam.nl/zoek). The design is not yet done for that.
  • Autosuggest
  • Different sizes
  • Tests for SearchFieldButton, will probably be part of an IconButton

@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 6, 2023 11:36 Destroyed
@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 6, 2023 18:49 Destroyed
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking good! Can we add a section where we explain the design choices we made, e.g. preventing autocomplete and spellcheck, and maybe the search label we hint for the ‘Enter’ key on virtual keyboards – which I didn’t know about, very nice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, good idea. Maybe we should wait until we reach a verdict on turning off autocomplete and spellcheck by default, or leaving it up to the dev?

({ children, className, ...restProps }: SearchFieldProps, ref: ForwardedRef<HTMLFormElement>) => {
return (
<form role="search" {...restProps} ref={ref} className={clsx('amsterdam-search-field', className)}>
{children}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not render the input and button ourselves? This allows putting anything in a search field, the button to the left from the input, etc. What’s the advantage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You often need access to the input itself, for autofocus, placeholder and to make it a controlled component for example. We could pass that all down from the parent component, but that would mean SearchField would need value, onChange (which would go to the child input), onSubmit (which would go to the parent component), autofocus, placeholder, etc. That's a bit messy imo. Its easier and imo more intuitive to have direct access to the input.

The button is separate because we also have SearchFields without a button, although the design for that isn't done yet.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, good reasons.

Copy link
Contributor

Choose a reason for hiding this comment

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

Should / Can we test submitting a value?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, out of scope.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, not really, it's actually a good idea imo. We should test the controlled version of the input

<VisuallyHidden>{label}</VisuallyHidden>
</label>
<input
{...restProps}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it intentional to disallow overriding autoComplete and spellCheck?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, but I wasn't completely sure about it. They're both kind of annoying when you're looking for partial text, especially in combination with an autosuggest component. We turned autoComplete off at Onderzoek, I'm not sure why we didn't turn off spellcheck. I see data.amsterdam.nl also turns autoComplete off.

I thought I stole the spellCheck part from gov.uk, but I see they don't have autoComplete and spellCheck turned off (anymore).

We could leave it up to the devs?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think setting them to off initially is actually the best MVP approach – setting them on indeed has UX side-effects.

In general, we should be explicit in making HTML-attributes overridable or not – i.e. specifying them before or after {...restProps}. I made a note to discuss later.

This comment can be resolved.

"outline-offset": { "value": "{amsterdam.focus.outline-offset}" },
"cancel-button": {
"background-image": {
"value": "url(\"data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 32 32'><path fill='%23004699' fill-rule='evenodd' d='M29.333 5.47 26.53 2.668 16 13.187 5.47 2.666 2.668 5.47 13.187 16 2.666 26.53l2.804 2.803L16 18.813l10.53 10.52 2.803-2.804L18.813 16z'/></svg>\")"
Copy link
Contributor

Choose a reason for hiding this comment

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

Sweet. Move the path into an icon token later?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure what you mean, do you want to create tokens for all icons?

Copy link
Contributor

Choose a reason for hiding this comment

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

I can imagine using background icons more often. We could have an icons.tokens.json containing the value for path.d, or the entire svg, to allow reusing it later. We should extend the build step creating React components to also create these tokens.

Just an idea. For someday. The current setup is fine for now.

@VincentSmedinga
Copy link
Contributor

The 'clear'-button currently uses native functionality, which only works in Chromium browsers (Chrome, Edge), not in Firefox for example. Is this functionality important enough to implement custom functionality for this?

I wouldn’t say so. Firefox users will be accustomed to not having a ‘clear’ button in a search field?

@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 8, 2023 09:08 Destroyed
@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 8, 2023 10:13 Destroyed
@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 8, 2023 11:22 Destroyed
VincentSmedinga
VincentSmedinga previously approved these changes Dec 8, 2023
"outline-offset": { "value": "{amsterdam.focus.outline-offset}" },
"cancel-button": {
"background-image": {
"value": "url(\"data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 32 32'><path fill='%23004699' fill-rule='evenodd' d='M29.333 5.47 26.53 2.668 16 13.187 5.47 2.666 2.668 5.47 13.187 16 2.666 26.53l2.804 2.803L16 18.813l10.53 10.52 2.803-2.804L18.813 16z'/></svg>\")"
Copy link
Contributor

Choose a reason for hiding this comment

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

I can imagine using background icons more often. We could have an icons.tokens.json containing the value for path.d, or the entire svg, to allow reusing it later. We should extend the build step creating React components to also create these tokens.

Just an idea. For someday. The current setup is fine for now.

<VisuallyHidden>{label}</VisuallyHidden>
</label>
<input
{...restProps}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think setting them to off initially is actually the best MVP approach – setting them on indeed has UX side-effects.

In general, we should be explicit in making HTML-attributes overridable or not – i.e. specifying them before or after {...restProps}. I made a note to discuss later.

This comment can be resolved.

({ children, className, ...restProps }: SearchFieldProps, ref: ForwardedRef<HTMLFormElement>) => {
return (
<form role="search" {...restProps} ref={ref} className={clsx('amsterdam-search-field', className)}>
{children}
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, good reasons.

@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 8, 2023 12:25 Destroyed
@github-actions github-actions bot temporarily deployed to demo-DES-507-mvp-search-field December 8, 2023 12:28 Destroyed
@alimpens alimpens merged commit dd1a437 into develop Dec 8, 2023
4 checks passed
@alimpens alimpens deleted the feature/DES-507-mvp-search-field branch December 8, 2023 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants