Is your feature request related to a problem? Please describe 🙏
There are times I'd like to make the <InstantSearch /> component controlled and it reads as if you can do so based on the Search state guide.
However, you can't arbitrarily pass state to the <InstantSearch /> component without also mounting a true (or virtual) widget like <SearchBox /> or <RefinementList /> algolia/instantsearch.js#2054
Describe the solution you'd like 🤔
I'd like to be able to be able to pass state to the searchState prop directly without mounting components like <SearchBox />
Describe alternatives you've considered ✨
If this isn't possible or it's a major lift then I think areas like the Search state guide and Routing and URLs guide could do more to clarify this requirement.
It would be great !!
Hi, thanks for opening the issue. Indeed we already thought to implement such feature. But with the current implementation of React InstantSearch it's a bit complicated to handle, because everything is drive by the widgets. See this thread for more informations https://github.com/algolia/react-instantsearch/issues/892.
I really don't understand the current implementation.
This is completely uncommon (= users will loose time in implementation) and too rigid.
Why making things so strange / difficult (widgets in React-Native?) when you better give us a Context like API or HOCs (standard and commonly used ways)?
There are higher order components available to make your own widgets @MacKentoch, see https://community.algolia.com/react-instantsearch/connectors/
Yes that is a good start.
Maybe is that just a problem of documentation (example of documentation issue with Configure widget saying there is no props):

But as an example of strange things is:
Configure components in InstantSearch parent, when I could just put configure value to some InstantSearch props?NOTES:
Hmm, that example of "no props" is definitely a mistake, it should accept all algolia query parameters.
The reason we chose to have different components is because we wanted the behaviour be component-based. This works for React on web, but also on Native.
This is because we see React InstantSearch as a UI-driven framework. This makes it declarative, rather than imperative, and is more readable in our experience.
You can use the connectors in React Native to replicate any of the components we have on web, and use their behaviour.
I'm not sure if you've seen our example with React Native (link), but also there we've been able to make the UI component-based.
Feedback is definitely welcome, and if you'd have a suggestion of what a better API would be, please let us know!
Oh and thanks for that note, I took your first comment in the wrong way 😄
I ran into this problem. In my use case, my search box was site-wide in a nav bar, and keeping it inside a InstantSearch context would be weird since the search results have their own page. Given that injecting the searchState prop turns the InstantSearch component into a controlled component, I was confounded that injecting the search state didn't work properly without a <SearchBox /> component somewhere inside.
In the end, I worked around it by creating a custom SearchBox that didn't actually render anything.
const InvisibleSearchBox = connectSearchBox(() => null);
<InstantSearch
apiKey={algoliaApiKey}
appId={algoliaAppId}
indexName="RedactedIndexName"
onSearchStateChange={state => history.push(`/search?${qs.stringify(state)}`)}
searchState={qs.parse(search.slice(1))}
>
<InvisibleSearchBox />
<Hits hitComponent={Hit} />
<Pagination />
</InstantSearch>
It's a dirty hack I wish I didn't have to do, but it did the job.
That's the way to go @JayAndCatchFire. We refer to these components as virtual widgets in the documentation.
Most helpful comment
I ran into this problem. In my use case, my search box was site-wide in a nav bar, and keeping it inside a
InstantSearchcontext would be weird since the search results have their own page. Given that injecting thesearchStateprop turns theInstantSearchcomponent into a controlled component, I was confounded that injecting the search state didn't work properly without a<SearchBox />component somewhere inside.In the end, I worked around it by creating a custom SearchBox that didn't actually render anything.
It's a dirty hack I wish I didn't have to do, but it did the job.