Giters

algolia / instantsearch

⚡️ Libraries for building performant and instant search experiences with Algolia. Compatible with JavaScript, TypeScript, React and Vue.

Home Page:https://www.algolia.com/doc/guides/building-search-ui/what-is-instantsearch/js/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RangeInput allow "from" to be greater than "to"

Nargonath opened this issue · comments

commented

🐛 Current behavior

The RangeInput component allows the user to enter a "from" value greater than the "to" value and trigger the search. The search doesn't return results which is expected.

🔍 Steps to reproduce

  1. Enter 300 in the first input ("from" input) of the Price filter.
  2. Enter 200 in the second input ("to" input) of the Price filter.
  3. Click the "Go" button.
  4. Notice the search is performed and no results are displayed.

Live reproduction

https://codesandbox.io/s/pedantic-greider-7xvg3j

💭 Expected behavior

The filter should not be applied. The "Go" button could be disabled and/or we could display an error message stating the range is invalid.

If you agree this should be part of the library, I can make a PR for it. Using the useRange hook we have access to start and range which give us respectively the current value in the input as well as the min/max values for the attribute. Using these two values we can identify the situation mentioned above and block the filter application/display an error message.

Package version

react-instantsearch 7.0.1

Operating system

N/A

Browser

Brave v1.57.62

Code of Conduct

  • I agree to follow this project's Code of Conduct
commented

I remember we had dynamic min and max set on the inputs at some point, but it was removed due to usability concerns. I don't remember the full history though, so we'd need to look at it again to see what the right solution would be.

For the time being, you can of course use useRange already and render the min and max yourself if you use your own inputs.

One thing to keep in mind as well is that changing the dom in most cases is a breaking change, so we can't just add a min/max dom property without this having impact for people eg already transforming or swapping the values already

commented

Sure, I understand @Haroenv. Having dynamic min/max would be best but what about disabling the "go" button? If we just add the behaviour it'd be a breaking change obviously but if we hide it behind a flag on the component then it would be opt-in until it gets passed as the default behaviour in next major version.

commented

As "disabled" on a submit button is also not always considered a best practice (source) I wonder if a custom rendering isn't the best way for you to go?

commented

Thanks for sharing the link @Haroenv that was informative. I know it might not be the best in terms of UX to disable the button when the component is in an invalid state as the user might not understand why without a proper message. For sure the behaviour I'm aiming for can be accomplished by a custom component but I wanted to avoid that route. I assumed that it's part of the nominal behaviour of this component since it doesn't make sense to search with an interval where the start value is greater than end value.

Is it fair to assume there won't be a change on the library side in that regards? If so, I'll close this issue.

commented

I'd like to see if anyone has another solution in mind (maybe a proper form with the browser validation on submit could work, but that also would require some rework on the ui side too), but for the time being, I think the most realistic is that we'll keep this component as-is.

Thanks for your feedback!

commented

Ok no problem. I'll keep the issue open then. Thank you for your help.