Create the InputField and SearchBar components

[dhruvkb]

Fixes

Fixes #374 by @dhruvkb
Fixes #375 by @dhruvkb

Description

This PR creates an input field component and search field component.

Testing Instructions

0. Run Storybook with npm run storybook.
1. Go to http://localhost:6006/.
2. Using the left pane, open the docs for
   • Components > Input field
   • Components > Header > Search bar
3. Check if the component looks and behaves as expected.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[zackkrida]

These look beautiful. Spot on to the figma designs. A couple of functionality notes:

• really like that the extraText is "dumb"—the parent can handle what this displays 👍
• I don't seem to be able to add a submit event listener to the <SearchBar />
• Just noting that the search input will become a combobox at some point to show the user their recent searches

[dhruvkb]

@zackkrida thanks for the heads-up about the combobox. Do we need to do something at the moment to prepare for this change?

I've changed the way the submit event works. Now it should be possible to directly attach to the @submit event on the SearchBar component.

[dhruvkb]

I'm also looking for ways to unify the AudioTrack.PlayPause button and this new SearchButton with Sara's VButton, but I'm having a hard time doing that. Maybe that can be a different future PR.

[obulat]

These look and work amazing!

[obulat]

Some tiny things I've noticed after looking more closely:

• The SearchBar's search button is rounded on the right in Figma, but not rounded in Storybook.
• In Figma, when the Search Input is focused, only the Search Input's border becomes pink, the border of the Search Button stays gray. When the Search Button is focused, on the other hand, the Search Button's border becomes pink, and the Search Input's border is gray. And in both states the input background is still white.
• If I understand correctly, only when we have a combobox, and when it is open and shows selections, is when the input background becomes gray, and the Search Button becomes pink. Am I right, @panchovm ?

[fcoveram]

You are right @obulat when it is a combo box, both elements react differently as separated.

[zackkrida]

LGTM after the small remaining fixes from @obulat. Great work!

[dhruvkb]

The button is actually rounded on the 'end' side, it's a bug with the Tailwind RTL plugin (fix merged) that prevents it from showing. Changing the direction to RTL and then back to LTR whould reveal the rounded corners in Storybook, but be2b67f provides a workaround for this.

[dhruvkb]

@obulat what you say about focused states in point#2 is already true. They behave in the same manner as you mentioned:

Input focus:

Button focus:

When you say 'focused', do you mean 'hovered'? Because if so, @panchovm mentioned in point#2 of his comment that the during hover both elements change into their hover style simultaneously (which is the reason behind ef73c50).

[obulat]

Thank you for detailed explanations with all the links, @dhruvkb !
I'm actually a little confused. I had an impression that the 'hovered' style is the same as the 'focused' styles. What I mean by that is: both the input and the button have a pink border. And only one element (input or button) is pink when it's focused.
And the styles from the Header Interaction section are maybe when you show the search suggestions, or leave the search bar (when it's not as prominent, which is shown using the gray background)?
@panchovm , could you please clarify this behavior? Sorry for tagging you here so much :)

[fcoveram]

No worries at all @obulat. I would try to explain it in two examples

Search navigated by keyboard

When the keyboard navigates, the first focused element is the search input, and then the search button. The style for both is focus since it's a selected element.

Search activated

When the user clicks on the search input to search for something, search input and search button change to focus & active style and the popover of recent searches appears below the input. This is because the search input was activated by the user.

[obulat]

One more quick question, @panchovm : What happens if the user simply hovers over the input, without focusing it or activating it?

[dhruvkb]

I'm also confused by the focus & active style (but in a different way). For users of the keyboard, the focus state is the active state. In that case, there will not be any hovering so will the input bar never be grey for them? In a sense, I'm confused what active means in terms of hover and focus?

Screen.Recording.2021-11-11.at.5.09.28.PM.mov

[fcoveram]

@obulat @dhruvkb
You are right about the input element as focus and active at the same time. In that case, the style is active focus. I missed the active focus for input on the prototype. Here are two examples for hover and active using cursor.

search.bar.all.states.mp4

My understanding about active states is that it depends on the component. For search input, the style is active focus since users can start writing immediately. In the case of buttons, the style is focus and changes to active focus when is activated.

Please correct me if I misunderstand it.

[dhruvkb]

I'm still having a bit of a hard time to understand so help me please. Let's not use the context dependent word 'active' for some time. Let's use the words 'hover', 'focus' and 'opened'/'closed' for the suggestion box. With this vocabulary, so far I have this:

[1] State hover: When I hover over the search bar (either input or button), input becomes gray & button becomes pink.

[2] State focus: When my mouse is outside the search bar and I Tab to the input, it gets a pink border.
[3] State focus: When my mouse is outside the search bar and I Tab to the search button, it gets a pink border.

[4] State hover & focus: When my mouse is inside the search bar (input becomes gray and button becomes pink) and I Tab to the input, it gets a pink border also.
[5] State hover & focus: When my mouse is inside the search bar (input becomes gray and button becomes pink) and I Tab to the search button, it gets a pink border also.

Also based on my understanding, the suggestion box will appear for states [2] and [4]. The presence of absence of the suggestion box will not affect the appearance of neither the input nor the button.

[fcoveram]

Replying per point:

(1): Yes.
(2): I'm not sure. Since you said that for input "focus state is the active state", I think search input should be gray with pink border. Use the active focus style.
(3): Yes.

Let me stop here. For points 4 and 5, I think we're understanding hover & focus as a state, but I defined that in the Design Library to indicate that hover state and focus state share the same style. It is neither a single state nor a single style.

(4): Yes
(5): I'm not sure. In terms of styles that make sense. But the pink with border style is for an element that is active. In this case, the user has not submitted a new search. I don't have a proper answer for this.

And your sentence about recent searches box is correct.

[dhruvkb]

@panchovm thanks! I think I understood your meaning a little more clearly now. I implemented

• point (2) of your comment in 616400a. This makes the input focus state same as active.
• point (5) of your comment in cc1ab67. This makes search button active state based on the HTML's :active.

Let me know if you think these changes match your vision of the component's behaviour.

[sarayourfriend]

Looking good so far! I noticed a couple of things. Additionally, the input does not span the visual width of its container:

This can be fixed by adding flex to the label container and flex-grow to the input itself.