Multiple OR RefinementListFilters produces weird behavior

When you select multiple options in an OR RefinementListFilter and then select one from another group, you can end up in a weird state as shown in the above screenshot. You can go to http://demo.fittery.com/twillory/ and pass in colors[0]=Red&patterns[0]=Stripe for an even weirder state where you can get stuck – only way to get out of the filter combo is to hit back or refresh the page.

The code in question for reference:

<LayoutBody>
  <SideBar>
    <RefinementListFilter id="colors" title="Colors" field="colors.raw" operator="OR"/>
    <RefinementListFilter id="patterns" title="Patterns" field="patterns.raw" operator="OR"/>
    <RefinementListFilter id="cuffs" title="Cuffs" field="custom_filters_a.raw" operator="OR"/>
    <RefinementListFilter id="collars" title="Collars" field="custom_filters_b.raw" operator="OR"/>
  </SideBar>
  <LayoutResults>
    <Hits mod="sk-hits-grid" hitsPerPage={100} itemComponent={ItemHit}/>
    <NoHits/>
  </LayoutResults>
</LayoutBody>

[GregoryPotdevin]

@joemcelroy It’s pretty easy to re-inject the missing values in the accessor’s getBuckets method

I’d like to point out, though, that we’ll be hitting a limit in terms of performance. We already have 1 component which dynamically transforms the returned buckets, and that’s MenuFilter (to add the “all” entry). The limit is that each time render is called it generates a new bucket and breaks the lazy re-rendering as the props aren’t shallowly equal anymore even if the data hasn’t changed. Injecting the missing value will have exactly the same issue.

I think the correct solution to this problem is to stop using the ES response as is and give the accessors the opportunity to update part of it when it is received. The same why the query is partially built with buildSharedQuery, when the response is received it could be passed to all accessors for transformations (like accessor.mapQueryResults ?). This could be the time to inject the “all” entry and missing values. SearchkitManager could keep a rawResults value to be able to re-run the map logic in case accessor options are changed (like having a showAll prop on MenuFilter).

This could also be used for infinite scrolling, by just letting an InfinitePaginator load more results and append to the query results (and let React refresh the whole list). Not good enough for cache management and random page access but that would require management the hits independently from the queryResults.

@joemcelroy I’ll try to post 2 PRs, one with a quick fix in the accessor that could be released as 0.9.4 and one to experiment with the query resulting mapping.

[Jaikant]

@ssetem @joemcelroy I am seeing the same behaviour, where the filters show only if there are available results to search within. If the filter is not applicable to the existing search results, the filter is not displayed. I think an option to yet display the filters would be great.