feat(index): compute local uiState

[samouss]

This PR introduces the concept of uiState into the index widget. Previously the uiState was only present inside the RoutingManager. Now it's a first class citizen of InstantSearch. One of its main usage will be the computation of the SearchParameters.

To keep the uiState up-to-date at the index level each instance subscribe to the change event on its Helper. Each time a widget (e.g. refine) or an index (e.g. add/remove setState) alter the state it triggers an update of the uiState.

The index now implements the function getWidgetState. This function will walk down the tree on each index to collect the complete uiState for the instance. The function will be useful to get the full uiState from the top level InstantSearch instance.

The format of the uiState changed. Each indices is now scoped under its identifier which is by default the name of the index (it will change to be able to target multiple times the same index). We've made this change because it's way simpler to work with a structure like this one. We don't have to branch to detect whether or not we are at the root (versus the one inside React InstantSearch). Any other ideas/alternatives are welcome!

Edit: With this new shape of uiState that would be nice to detect whether or not we are in a single/multi index context. That would allow us to preserve the current shape of URL with a single index. We can investigate when we adapt the routing mechanism.

Old format:

{
  "refinementList": {
    "brand": ["Apple"]
  }
}

New format: non back-ward compatible

{
  "instant_search": {
    "refinementList": {
      "brand": ["Apple"]
    }
  },
  "instant_search_price_asc": {
    "query": "iPhone",
    "menu": {
      "categories": "Phone"
    }
  }
}

Alternative format: back-ward compatible (React InstantSearch)

{
  "refinementList": {
    "brand": ["Apple"]
  },
  "indices": {
    "instant_search_price_asc": {
      "query": "iPhone",
      "menu": {
        "categories": "Phone"
      }
    }
  }
}

[Haroenv]

I like the change in the shape of uiState, because it avoids us to branch all over the place. However, I wonder if we could make the default stateMapping remove a nesting level if there's only one index.

[francoischalifour]

Since we have keys for all indices (which is the way to go IMO), how are we going to handle URL routing?

My guess would be that when we detect there's a single index used, we keep the same structure as right now. Once there are multiple indices, we change the structure of the URL. This won't bring breaking changes, which is delicate when it comes to routing because we break all existing URLs.

[samouss]

Since we have keys for all indices (which is the way to go IMO), how are we going to handle URL routing?

My guess would be that when we detect there's a single index used, we keep the same structure as right now. Once there are multiple indices, we change the structure of the URL. This won't bring breaking changes, which is delicate when it comes to routing because we break all existing URLs.

Yes forgot to mention it inside the description (I've added it), but the idea is to be able to detect somewhere (state mapping? before the call to state mapping? This can be decided when we adapt the URLSync) that we are inside a single/multi index context. For a single index, we should keep the same shape of URL that we have today. For a multi-index then we use the default serializer. Note that if users wrote their state mapping they might have to update themselves to match the new structure (depends on the solution we choose).