React-instantsearch: Provide UrlSync provider

[mthuret]

Use case: Today if you want to have an url synchronisation we provide recipes but we don't provide a ready-to-use module. However there's a pattern that is always there (pushing after N ms) and this could be abstracted. Also it could be great to provide ready-to-use provider for the most popular way to handle url sync.

Also, there's an underlying issue when it comes to synchronise our JS libraries with mobile librairies. See: https://github.com/algolia/react-instantsearch/issues/111
For now let's put this outside of the scope as it requires some modifications including different libraries (mobile is not handling disjunctive faceting, we do not represent it in our search state).

Api proposal:

I propose to have an interface call createUrlSyncProvider that takes an object expecting three functions: pushToHistory(searchState), getFromHistory and createUrl(searchState).

This interface can be use to create several ready-to-use provider: ReactRouterUrlSyncProvider, BrowserUrlSyncProvider, NextUrlSyncProvider...

Those providers can take several props:

onSearchStateChange: if the user still need to listen to the searchState.
searchState: if a searchState needs to be pass to turn InstantSearch in control mode.

Usage:

<UrlSyncProvider>
    <InstantSearch
      appId=""
      apiKey=""
      indexName=""
    >
      <Configure hitsPerPage={16} />
      <Header />
      <div className="content-wrapper">
        <Facets />
        <CustomResults />
      </div>
    </InstantSearch>
</UrlSyncProvider>

[Haroenv]

For the record, the urlSync provider we use in Yarn (which is mostly based on the issue here) is potentially responsible for the "sends more than one request per query", so we should be careful that our connector doesn't have that issue

[mthuret]

@Haroenv that seems like a bug to me. If you used the recipes we provided and can find a fix, please fix them. Also I wasn't able to saw this behaviour in our e-commerce demo (using a simple browser url sync).

[Haroenv]

Okay. Then the issue is coming from somewhere else. Thanks for checking

[vvo]

Can you show a more complete proposal API example that uses:

• createUrlSyncProvider
• react-router

?

[mthuret]

Yes sure, here is how you would use createUrlSyncProvider (here for browser url sync)

const BrowserUrlSyncProvider = createUrlSyncProvider({
  pushToHistory(searchState) {
    window.history.pushState(searchState, null, this.createURL(searchState));
  },

  getFromHistory() {
    return qs.parse(window.location.search.slice(1));
  },
});

As for React-Router, it would be the same usage as BrowserUrlSyncProvider, a component that wrap InstantSearch.

[vvo]

LGTM and really looking forward to also the pre-built providers.

One thing maybe to draft an API for too is an easy way to:

• alias state parameters ("state.query": "s")
• ignore state parameters (ignore: ["state.page"])

What do you think? Handling this could be some good boilerplate code for the user that we can maybe save him in a reusable package.

[bobylito]

I have a question on that topic. Why can't it be a parameter of <InstantSearch/>?

[mthuret]

@bobylito: can you elaborate? what API do you have in mind?

Some insight of why I went for the Provider pattern:

• Common pattern as soon as you need to add feature on top of a core one. ex: ThemeProvider
• decoupling InstantSearch from UrlSync

Some cons I remember:

• dealing with onSearchStateChange/searchState

[bobylito]

Happy to oblige :). I was wondering if we could add a urlSyncProvider prop on InstantSearch to which you can pass the same object that you would pass to createURLSyncProvider. Does that make any sense?

[mthuret]

I don't have strong opinions here, that could work too.

[mshanu]

While trying to implement UrlSync myself following the example, since its using qs, if we serialise an array, the key gets repeated and can bump up the url size. Would you be thinking about length of url as well.

[bobylito]

@mshanu there are two ways to approach this problem and so far InstantSearch.js (based on the JS Helper) try a generic one. And that's why you will get artifact such as those repeated keys. However of this proposal and future developments in this direction will aim to provide the tools to make a URL sync mechanism that could be tailored to your needs. You would then be able make URL's as lean as possible and closer to the business logic of your search.

So in short, yes the goal is to be able to make shorter and cleaner URLs :)