vectara / react-search Goto Github PK

For insights purposes, we can add a header param to queries coming from search. This helps us measure the usage of this component to query our API/

This will be useful for any device that lacks an “Escape” button, e.g. a touchscreen. This also will fix a critical bug on smaller touchscreens, because on those devices the modal occupies the entire screen and there’s no way to dismiss it.

This hook currently returns { fetchSearchResults, isLoading }. I noticed two things:

• We're using two different verbs to describe the same action: "fetch" and "load"
• The action is verbose but the state is terse

I think we can reconcile these differences and create more symmetry between the action and the state. I suggest erring on the side of verbosity to avoid potential conflicts with the consumer's variables, e.g. a local isLoading variable. I'd suggest { fetchSearchResults, isFetchingSearchResults }.

Currently, setting isDeeplinkable will persist the search query to the search query parameter. This could collide with a query parameter already in use by the consumer. We can resolve this by providing an option for persisting the search query to a different query parameter.

When configured, these suggestion topics will show up in the search modal when the user hasn't executed a query.

@mrderyk You were right -- it would be nice to be able to customize this button's text! 😅

Currently, this links to the url metadata.

We need to verify that this won't break projects on React 18.

Relates to vectara/vectara-docs#227

react-icons currently takes up over 83% of our bundle size. Let's look for an alternative, since we only need one icon, and deep-importing from react-icons doesn't look to be working.

We can support basic themes that change the color scheme, e.g. green, orange, red, dark.

The component needs to handle errors and surface them to the user.

Search results can be configured with arbitrary metadata, and the consumer should be able to use this metadata to drive how a search result is rendered. One solution could be to provide a search result deserializer prop and a render prop.

We can use tabs to provide access to both the current search results, as well as a summary of the results. We can use localStorage to remember the user's preference so that they don't have to keep selecting the tab they want.

We need to publish type definitions for TS codebases that consume this component.

We should consider the user journey from using this component in prototypes (API keys) to using it in production (OAuth).