Add the search input, and catch up on some tests

[dpasque]

What Does This PR Add/Change?

• Adds the search input to the duplicate searching page
• Removes much of the placeholder filler
• Makes search inputs match the style guide more
• Adds handling to not search if there's no search term
• Backfills the component tests for search results over the course of the search lifecycle

Testing Instructions

• [x] Unit tests pass
• [x] No Axe devtool errors

Issues

Related to #
Closes #63

[dpasque]

@john-legg @karenroldan hi! 👋 😄

Karen, I love the two ideas you brought up above! 😄

While the current implementation prevents a new search when the user clears the input field, it might be beneficial to display the initial search state or clear the current results. In that way, the search results also reflect the current input. What do you think?

To minimize the number of search requests and reduce the amount of returned results, should we implement a minimum character limit before initiating the search, such as 3 characters? This approach can help prevent performance issues, especially when dealing large datasets.

John, I was wondering if you had any strong opinions or other design guidance for these two ideas?

Re: the minimum character limit, I've done things in the past where the debounce (searching after a delay) is restricted to a character limit, but you can always press enter (or the search button) to override that and fire the search anyway. I wonder if that might be a good middle ground?

[john-legg]

when the user clears the input field, it might be beneficial to display the initial search state or clear the current results.

I'm so torn on this 😭 On one hand, the current implementation seems useful to allow users to redo their search keywords while being able to reference their previous search results. This is also how Google and Big search results work as well.

However, Google and Bing searches don't debounce the results. I asked GPT and it agrees with Karen's suggestion:

It is generally better to clear the results when the search box is cleared of search terms. This provides the user with a clear indication that their previous search has been reset, and they can start a new search. However, it's essential to consider the specific use case and user expectations for your product, as there might be scenarios where keeping the previous results would be more user-friendly.

I agree that it's beneficial to have the search results reflect the search box for consistency, especially since the results instantly update when search terms are manipulated. From a design perspective, I would imagine a cleared search bar would display the initial state with illustration. I could go either way, honestly. Any thoughts, Dan?

should we implement a minimum character limit before initiating the search, such as 3 characters? ... I've done things in the past where the debounce (searching after a delay) is restricted to a character limit, but you can always press enter (or the search button) to override that and fire the search anyway. I wonder if that might be a good middle ground?

I think that's perfect, actually! The user will always have a way to "override" the three character limit using those methods. Great suggestion, Dan and Karen 👏

[dpasque]

@john-legg @karenroldan sounds good! 👍

If it's okay with you, I'll put the search clearing behavior in its own PR. That way if we decide later (like in user testing/feedback) that we want to take it back to persisting the results, it's just an easy single revert!