Instantsearch.js: Prevent sort RefinementList onChange

[Kikobeats]

Not sure if is possible, but desirable in my case.

Could be possible prevent put on top of the list the marked items?

My RefinementList implementation is here.

[bobylito]

Thanks @Kikobeats for the issue. This is done when sorting the values. It is possible to change the order with a custom widget and a connector.

[vvo]

@bobylito @mthuret Do you think we should provide a generic entry to reformat the data? Not a sortBy, not a map. Just a simple method where you can either filter/reorder as you want based on the provided props.

I know we took the path to say "widgets => no options". But since we also made the move from "no css => good css", if we actually want people to use a bit of our widgets, maybe we could be a little bit more flexible here?

We actually had multiple people already telling us "the default sortBy is not the one I expected".

We do have SOME options (limit, showMore..). We just need to find the right set of options that handle many use cases, sortBy is limiting, let's make it a complete reduce (well, you will still need to send some array items, but you can do whatever you want with them).

I propose:

• draft API proposal for exposing transformProvidedProps on every connector
• default transformProvidedProps in lists should be alpha + count instead of isRefined + alpha + count

What do you think?

[mthuret]

I think this a good idea to bring some flexibility.

With this, a widget user will also be able to push some pre-defined data. So actually there's is several use case for it.

I didn't get this part though: 'default transformProvidedProps in lists should be alpha + count instead of isRefined + alpha + count?'?

[vvo]

I didn't get this part though: 'default transformProvidedProps in lists should be alpha + count instead of isRefined + alpha + count?'?

Today the default sort we do in lists is: if it's refined, it's on top, then we use alphanumeric + count sort. We should maybe just use alphanumeric sort so that users are not surprised..?

[mthuret]

Maybe on the default behavior we can check before (with CSE?) what would be the one we want to push for? As long as we can override it, it should be fine, no?

[bobylito]

The facets are dynamic based on the result set. Removing isRefined means that the selected values may disappear, which is also confusing for users. I think that there is no perfect solution here, but at least end-users (not devs) will be less confused by moving values than disappearing values.

[bobylito]

Some thoughts on the topic:

• the sort strategy depends on the number of facet values. If you have few, you probably want something static because there is little to no risk that the value will disappear. The opposite is true, if you are likely to loose the values you probably want to keep them
• what if displaying the selected values in the list is not important? What if we could display them on top of the list, without altering the order to fit the need to keep the selected values on sight?

[bobylito]

maybe we could be a little bit more flexible here?

👍 Sorting is at the fringe of the UI but not quite, imho.

[vvo]

what if displaying the selected values in the list is not important? What if we could display them on top of the list, without altering the order to fit the need to keep the selected values on sight?

I thought about this also but displaying them on top of the list would do exactly what we do today no? Even if we show them inline (a bit like CurrentRefinements) they would still jump from the list to the top.

[vvo]

You can no do it with transformItems, see https://community.algolia.com/instantsearch.js/react/guide/Sorting_and_filtering.html#example