[numericSelector] Issue when selecting undefined

[Jerska]

When selecting an option with the undefined value, we get an error back from Algolia.
We should probably just clearRefinements in that case.

[vvo]

How can this happen that we display a value that will refine to undefined?

[Jerska]

See the dev/app.js, popularity selector.

[vvo]

I am sorry the easiest way to report this bug or any UI bug is to quickly drop a GIF explaining it. So all devs will get the issue in no time VS having to try to understand the bug.

Can you do that?

[Jerska]

Don't mind the console logs and warnings, the issue is just with the last error displayed.

[vvo]

Now I immediately get it, in particular the "undefined value" which I did not understand at all, thx

[vvo]

We should probably just clearRefinements in that case.

Seems reasonable and should not introduce something people do not want.

Also in terms of UX I would just not put any "Select a value" option in our demo app. Seems obvious that this select menu is.. for.. selecting a value. But rather set the default to the "default" sorting

[pixelastic]

Not sure we should clearRefinements in that case, this seems a bit overkill (will reset all faceting defined). I would rather simply fallback to the default index.

[vvo]

I would rather simply fallback to the default index.

Indeed seems like a better idea.

[bobylito]

Will it be obvious for the user that an index is selected and which is the one selected?

[bobylito]

Also I'm not sure that having 2 index selector is such a good idea. One should change the other, right?

[bobylito]

Also if you change the index, the previously selected filters might not be relevant. How should we deal with that?

[pixelastic]

Will it be obvious for the user that an index is selected and which is the one selected?

We will always advocate for not having an "empty" value in the list, and always select the default one. But I'm ready to bet that some users will want to add an empty element (maybe because this is how their CMS forces them to do), so we need to handle that gracefully. Going back to default is the one that will raise the least surprise I guess.

Also I'm not sure that having 2 index selector is such a good idea. One should change the other, right?

Yes... I do not understand the UI either. Seems weird to me

Also if you change the index, the previously selected filters might not be relevant. How should we deal with that?

That's also true, and I think we discussed it with @jerskouille and @redox in the past already. Not sure how to handle it, but that should be a different issue.

[bobylito]

That's also true, and I think we discussed it with @jerskouille and @redox in the past already. Not sure how to handle it, but that should be a different issue.

I think that's the point of using clearRefinements. This way we avoid the weird effect of having unknown/non-applicable filters.

An other strategy could be to leave the currently selected filters, and provide a way to discard the filters one by one with something like the widget proposed by @jerskouille #404. But then the user has to manually remove all the filters (may be lots of clicks).

[Jerska]

@pixelastic :

Not sure we should clearRefinements in that case, this seems a bit overkill (will reset all faceting defined). I would rather simply fallback to the default index.

You can clearRefinements on a specific attribute. But we could probably access the previous refined value and remove this specific numeric refinement.

[vvo]

About the original issue and requirement ("Select a value").

Maybe we can add a "header" API option entry where you could add your own "Select a value". I feel that would fit the need pretty well and we would then have to document that if the user select the header then we select the default index.

Then if the user passes an "undefined" value for the sortBySelector we should error and says this is not doable.

Works?

[vvo]

I added "need api proposal" to this one because relying on the "undefined" value to trigger a behavior like clear refinement and provide a "header like" feature is not clear enough for the user.

[pixelastic]

What about simply passing the default index name as the value of the label entry? This would allow people to select the label entry.

Regarding undefined, I would not throw an error if such a value is selected but simply revert to the most sane value (default index) as to not break everything for the user, but still display a warning in the console for the developer.

[vvo]

What about simply passing the default index name as the value of the label entry?

I do not understand: which label are your talking about?

[pixelastic]

Let me rephrase it.

A common usecase for select elements is to have the label as the first value of the dropdown instead of being displayed on the side.

As first element

On the side

When putting it as first element, you still have to put a value, and in this bug report we had a user that puts an empty value. This resulted in trying to switch to an index named undefined, which ended up as an error.

What I suggested was that if we see that there is not value set for the dropdown option, instead of passing undefined and failing, we could be smart and use the default index instead. From a UI POV this is what the user is expecting: Reverting to no value should actually revert to the default index.

But in the meantime, we can provide a workaround for this issue without having to code anything. We could simply tell our user to pass the default index name as the value for the Select a value option instead of passing an empty string. This will have the exact same effect.

[vvo]

As for sortBySelector, it may be an anti pattern to try to provide this option (showing "Select a sort"). Because there's always an index sort selected: the main one which should be the "most relevant" default option.

As for numeric selector, I moved to #885.