Questions about using Combobox for Search

[yannieyip]

1. Currently, we have the following optionTemplate set on the Combobox in order to render different views based on the query string and/or search results. In the case of valid results, the anchors/links are rendering properly. In the other cases, the text gets rendered but still behaves as links.
   From console inspection, we see that on hover, a text-decoration: underline being applied by some parent component. Even when we tried setting textDecoration: none on the Text elements below, the parent style still overrides the ones we set. So they get rendered as hoverable/clickable links instead of just text.

optionTemplate={(item: any) => {
            return searchResults.loading ? (
              <Box marginBottom="space100">
                <Loading />
              </Box>
            ) : searchResults.data && searchResults.data.length > 0 ? (
              <Anchor data-testid={item.name} href={item.url}>
                {item.name}
              </Anchor>
            ) : !!query ? (
              <Text data-testid="empty-text" as="p" textAlign="center">
                No results matching "{query}".
            ) : (
              <Text data-testid="default-text" as="p" textAlign="center">
                Search within your Console account or our documentation and help
                center.
              </Text>
            );
          }}

Any idea why we're seeing this behavior? Is there something we're missing or could this be a limitation on Combobox?

2. Would it be possible to remove/hide the chevron icon at the right of the input box?

The Combobox is working for the most part for Console Search, except for these couple UI issues, so if there's anyway we can make changes to our implementation instead of building our own component altogether, that'd be very helpful.

[richbachman]

Hi @yannieyip

Currently we are setting an underline on hover for the Combobox items. We may need to reconsider that for users passing their own optionTemplate. Will you share a screenshot or codesandbox where you're seeing the issue. That will help us consider the use case.

For question two, we do have a backlog ticket to make the chevron removable.

What is your timeline for this project? Thanks.

[serifluous]

We're planning on hiding the chevron only when autocomplete is on in the combobox, so +1 to seeing a screenshot/codesandbox to make sure that this ticket will help resolve question 2: https://issues.corp.twilio.com/browse/DSYS-2285

[richbachman]

Hi @yannieyip we released an updated Combobox package yesterday with the fix for the hiding the chevron when autocomplete is enabled. If you update your Paste packages, you should see that change.

[yannieyip]

@richbachman Thank you! I'll pull in the update on our side.

[yannieyip]

@richbachman @serifluous - Thank you both for the prompt replies. I've attached some screenshots with explanation below.

A) For the first 3 cases (initial message, loading search results, empty search results), we used the optionTemplate logic above to render text/loading spinner. As you can see, I'm hovering in the screenshots and they behave as links. This would be a great use case to cover (removing underline/link styles to all children), especially for list of data fetched via backend APIs, in which case different views/error states would likely get displayed in different styles.

B) You can see the chevron icon in these screenshots, which is a bit confusing for certain results being shown. We do have autocomplete set on the component, so the ticket DSYS-2285 looks perfect for addressing the issue.

This current work is for the new Console Navigation launch due in 4 weeks. So, if Paste could squeeze in these updates in your next sprint or two, that would be amazing!

[yannieyip]

@richbachman I forgot to mention - we discovered one more issue that might be a bug. On the initial case, the input (query string) is an empty string. When we tested with the following snippet:

export const Default = () => {
   const [query, setQuery] = useState("");
   return (
     <Search
       query={query}
       searchResults={defaultResults}
       onChange={(newValue: string) => setQuery(newValue)}
     />
   );
};

The display still works, but with the following console error
downshift: A component has changed the uncontrolled prop "inputValue" to be controlled. This prop should not switch from controlled to uncontrolled (or vice versa). Decide between using a controlled or uncontrolled Downshift element for the lifetime of the component. More info: https://github.com/downshift-js/downshift#control-props

It seems like the downshift component in Combobox doesn't like when we flip from an uncontrolled to a controlled input. Or perhaps there is something wrong with our implementation?

[SiTaggart]

@yannieyip do you mind starting a separate discussion for this point, if it's still an issue. We want to try and keep discussions focused to distinct topic areas to make them more searchable for future Twilions

[yannieyip]

@SiTaggart Makes sense! I opened #822 as a separately discussion.

[richbachman]

Hi @yannieyip. Thanks for the screenshots and the code snippets for the potential bug. We'll create some tickets and get them prioritized. We'll keep you posted.

[yannieyip]

Thank you! I'll wait to hear back from you.

[SiTaggart]

Hi @yannieyip, I have follow up comments regarding the option content and styling and arguably this is just an issue with alpha components not having full documentation yet that covers certain edge cases.

So a combobox is a form input. You are setting the value of the combobox based on;

• selecting an option from a listbox of valid options we show below the input
• or if its an autocomplete combobox, by typing in an arbitrary string into the input.

Upon setting a value, you can choose to perform "some action" based on onChange of selecting a valid option, or submitting the form the input is contained in if it's an arbitrary string (performing a generic search, for example, type a random string, hit enter, perform the search on string contents).

For assistive technology to be able to machine read the contents of the listbox popup, everything we show must be a valid option. Meaning it is technically selectable, and that in turn comes with content constraints.

So the fact that any option gets underlined on hover, is reasonably by design, as it must be selectable if you want me to be able to read the text using assistive technology.

The second part is an option "must not" (air quotes are important as there is nuance in that) contain further or additional actionable content. So for the no results option, we can't have the word, "documentation" as an anchor. The whole thing has to be the action. (I'm fairly sure that came up in design review and hand over of the console nav designs). By all means, throw a <Text /> around it and change the color of the word to get the same visual, but the action to go to the docs must be selecting that option from the list by clicking on the whole thing or pressing the enter key, not clicking that one word.

The nuance in "option must not contain actions" is that if you are performing a page navigation as a result of setting a value, you might want to expose the cmd+click behaviour of the browser so the link opens in a new window. Obviously we can't recreate that using an input or onChange events. In that case I would not use the <Anchor /> component, but just use the Text component and recreate an HTML anchor for click purposes. Just make sure too add role="presentation and tabIndex="-1" to it like so:

<Text 
  as="a" 
  href="http://foo.com"
  role="presentation"
  tabIndex="-1"
> 
  {optiontext}
</Text>

All of this will go into the docs eventually once we write them.

[yannieyip]

@SiTaggart - Thanks a lot for the thorough explanation. I'll take this back to my team and with this context decide what our next steps should be.