React InstantSearch v4.1.3 is out 🎉

Hi everyone,

We’re pleased to announce the release of React InstantSearch 4.1.3

Since 4.1.0 we worked on fixing few bug fixes, a new API and redoing the whole design of our community website.

connectStateResults new connector!

When dealing with conditional display such as no results page, you were forced to use the createConnector API. The purpose of this API is mainly internal and used for creating new connectors. With its current shape, it might be tricky to understand and ultimately we could deprecate it to propose something easier.

As creating conditional display page is pretty common use case, we decided to wrote a new connector called connectStateResults. It allows you to create new components able to deal with conditional display but also with any use cases requiring access to the searchState, searchResults and other InstantSearch informations.

Guide: React InstantSearch | Conditional display
API documentation: React InstantSearch | connectStateResults

If you’re concerned about this new API, a warning will let you know. We encourage you to migrate as soon as possible.

Bug fixes

React 16 warning

*List were producing a warning since React 16.

Start testing React 16 · Issue #215 · algolia/react-instantsearch · GitHub

Multi indices API

  • You can know update indexName props. This will trigger a new search.

Can’t update prop indexName of Index · Issue #304 · algolia/react-instantsearch · GitHub

  • Page is now reseted to one if a shared widget refines.

InfiniteHits with multi-index: hits don’t update · Issue #310 · algolia/react-instantsearch · GitHub

Many thanks to @nicolas.torres to pushed the multi indices API further than anyone before!

a new websites design

@lucas.bonomi did an awesome work at updating our community website with a whole awesome new design that fit the Algolia one. Check it out!

How can you help?

If you’re using this new version and have any feedbacks for us, please give it on discourse or GitHub :slight_smile:

Happy coding!


@marielaure.thuret Super excited about the connectStateResults connector! :clap:

How would you recommend using it with an autocomplete? Can we compose the connectStateResults connector with the connectAutocomplete connector?

Also I think there may be a syntax error with this example:

I’m not sure what it was meant to be, but the return statement on line 14 doesn’t appear to be wrapped inside a function.

Hi @nchaves, thanks for catching the doc mistakes!

What’s your use case to combine the autocomplete and the connectStateResults?

Happy to help, Marie! I’d be happy to work on a PR to fix that section of the docs, but I don’t actually know what the code snippet is meant to be :sweat_smile:.

As I think more about our use case, I’m not sure that connectStateResults will actually be applicable (still a very cool connector though). But I"ll describe our use case anyways:

We developed an autocomplete using react-instantsearch (with connectAutoComplete) and react-autocomplete. The autocomplete displays search results in a dropdown menu. It works great! However, an issue occurs if the user does the following:

  1. type “a”, which returns several results in the dropdown menu
  2. press DELETE, which clears the query
  3. type “b”

When the user types “b”, the dropdown will initially display the results that corresponded to the “a” query. In other words, there’s a brief flash of stale/incorrect results. Once the results for the “b” query are returned, the relevant results for the “b” query will be displayed.

I’m not sure if there’s a way to avoid this with the current API. Any suggestions? I think these issues about the initial search state are related:

In our case and the 2 cases above, I think the fundamental problem is that we don’t always know what query caused the current hits prop in connectAutoComplete. There are simple workarounds for the “unwanted initial results” issue, but I think it would require a more complicated “dirty check” for the “flash” issue I described.

I do think the core issue is that we need a way to associate the hits prop in connectAutoComplete to the query that caused those particular hits. If you agree, then maybe we could pursue something like this:

connectAutoComplete could have a prop named something like hitsQuery. This prop would be the query that caused the current hits prop. Note that hitsQuery would not always be the same as currentRefinement. In the example I gave, just after the user types “b”, the props would be:

hits=["apple", "avocado",...] (whatever the results from the “a” query were)

Once the results for the “b” query are returned from the server, the props would be:

hits=["banana", "blueberry",...]

That way, the application developer could easily determine whether they want to display the “stale” results by comparing hitsQuery to currentRefinement.

I do think this is feasible since the underlying Algolia REST API returns the query along with the hits returned by the server. WDYT? Maybe there’s a cleaner approach, or maybe I’m not actually addressing the fundamental issue.

Hi @nchaves,

Indeed, this happens because when performing a new search, results are not reset to each time (otherwise you’ll have a blink UI). Here it’s an issue because when nothing is type in the input, results are hidden and therefore when a change occurs, you didn’t expect previous results (or an empty query for that matters).

I’ll open an issue on our github repository because this needs to have at least a guide in our website if a better API/fix can’t be found as it’s pretty common as soon as you have a slow network.

One thing you can do is tracking the value of your autocomplete in its state. If this value is empty when new props are received, you can consider that the hits are also empty. See this example I made using the autosuggest react component: (not the same as you used but the idea should be the same).

You can also track if a search is in progress by using the using the connectStateResults connector and the searching props.


Thanks soooo much @marielaure.thuret! Works great now! Yep, the piece we were missing was to pass [] instead of hits when the value is “”.

Thank you for taking the time to make the sandbox! And thanks for opening the Github issue. If I have any ideas, I’ll bring them up there.